Hacker Newsnew | past | comments | ask | show | jobs | submit | lowestdecks's commentslogin

I share the author's skepticism that Cox would have ever been capable of this. Especially not at the scale that was claimed in the deleted B2B marketing materials.

While there are reasonable concerns over access to microphones in various devices found in consumer's households, especially cheap IoT devices (although, I'm EXTREMELY about claims that any agent is listening to unfettered microphone access on smartphones, given the restrictions that have been put in place to get access to microphones), I don't believe that a limited scale (compared to any big tech) cable company could have the engineering chops to pull this off.

Things that would be required: * getting this system to work with an exceptionally large variety of devices from nearly as many brands. * having nation-state quality malware to get access to the microphones on many of these devices (either from the manufacturer not wanting to work with them or not incentivized to work with them) * battery powered devices not facing user-noticeable power draw (think a Dualshock controller) * having advanced enough AI (bigger issue 2 years ago than it would be now) at a very large scale filtering out noise and categorizing conversations such that they are useful to advertising partners (probably possible now with the vectorization techniques in LLMs) * having the AI be cost effective at that scale without local processing (unlikely to locally process on the devices themselves due to processing power limits; unlikely to locally process on their modems because cables modems are made as cheap as possible to offer the services that they are selling, without a FLOP more); this is a much bigger roadblock than the advanced enough AI * actually hiring talented enough engineers to accomplish these things (especially the AI)

And frankly, they are such a small player in the grand-scheme of things, they would be idiotic to not also be selling this tech to every cableco/telco in a developed nation, in order to get their money's worth. This would be 'discuss it at the shareholder meeting' important if that much money was spent and they wanted to get their value out of it, since they are otherwise limited to where they can physically roll out Cox cable.

Frankly, a bunch of marketing hot air (that they've since removed).


You're getting too far into the weeds with the IOT and smartphones. TFA talks about mics in the cable boxes and smart tvs. I wouldn't put it past them to monitor mics in cable boxes.


Set-Top Boxes and Remotes have had mics.


Or have 470 really shady apps with a small install base that actually include a listening SDK (with the microphone warning from the OS showing), then pad the rest with garbage data from other sources to pretend their solution covers more than the very few users it does.


Real world example of a use of TPMs (outside of bootloaders) that has a positive effect on users: https://blog.chromium.org/2024/04/fighting-cookie-theft-usin...


How does DBSC improve adtech at all?

The proposed design makes no mention of using TPM/device attestation and explicitly calls out that it is bound to the same restrictions that Chrome's removal of third-party cookies is introducing.

If a site (Google or other) cannot get an attestation with the key and keys are unique per eTLD then there's no new tracking vector introduced. A site can't get anything more than they can with a standard, first-party session cookie.

> just force log me off of sites after a time limit

Since this opinion is seriously in the minority as the overwhelming majority of people do not like the friction of having to log back into services, that's never going to happen for any sizable fraction of websites [†].

Thus, for everyone's security it would be better if sites adopt DBSC to prevent session-theft/cookie-theft without introducing the nuisance of constantly logging in.

Not to mention, every log-in with a password is opportunity for phishing/key-logging. If people had to log in 10-100x more frequently, that would only increase another form of malware. Only FIDO/Passkeys offer the ability to make frequent log-ins phishing resistant.

[†] - banks being a big exception since, prior to DBSC, there was no good way to prevent session-theft/cookie-theft outside of making sessions/cookies very short-lived. And they need to be worried about session-theft/cookie-theft because... money.


Passkeys are at the beginning stages of support both from the perspective of platforms (OSes, browsers, passkey/password managers) and websites. e.g., Firefox is still figuring out how to support passkeys from OSes and passkey/password managers (e.g. https://connect.mozilla.org/t5/ideas/support-webauthn-passke...) and will likely (this part is just speculation) support Firefox sync as a passkey manager eventually.

This is why there is no major website that is requiring users to drop passwords yet. Nor am I aware of any that allow users to even choose to drop passwords yet.

> If I choose the passkey option Passkey stuff comes up on Safari and I’m 80% sure that means I can’t use that passkey with my PC? I don’t know how to make sure my passkey isn’t lost by switching devices.

If you're saving your passkeys to a credential manager (i.e. password & passkey manager), once there is support from Firefox and your credential manager of choice is plugged into any prerequisite APIs, you will be able to use your passkeys between Windows, Mac, iOS, Android, Safari, Firefox, etc.

Devices like Steam Deck, Meta Quest, smart TVs may require additional support added. I'm not super familiar with the platform, but Steam Deck should be fully capable of supporting passkeys through hybrid flow. If it is running a chromium browser and has Bluetooth support, it would be trivial to add support for hybrid flow with a phone as the authenticator (that is: the phone has the passkey and signs a challenge with Bluetooth assistance). Smart TVs already have in place methods to login using a local smart phone, tablet, or laptop (which would use the passkey). I can't speak for Meta Quest because I have literally no idea how that platform works.

---

As for the median user globally: the median global user has 1 device: their smartphone. Passkeys are so simple in that case. These users likely are not using any credential manager other than the one built in. Each of these major platforms (except maybe for some Chinese OSes that I'm not familiar with) already has recovery mechanisms in place for when users lose their device.

The next largest group has 2-5 devices, with basically all of them able to work just fine using the phone as a hybrid authenticator.

You are not a simple case. In fact, anyone that chooses to use a non-platform credential manager is not a simple case.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: