Fighting cookie theft using device bound sessions | Hacker News Reader

Fighting cookie theft using device bound sessions

blog.chromium.org

37 pointsfeross11 comments

> We are committed to developing this standard in a way that ensures it will not be abused to segment users based on client hardware. For example, we may consider supporting software keys for all users regardless of hardware capabilities. This would ensure that DBSC will not let servers differentiate between users based on hardware features or device state (i.e. if a device is Play Protect certified or not).

Personally I do not believe this for a second. Yes I do believe that this is what they will do now. But in a few years, if DBSC becomes mainstream? I fully believe Google will start abusing this to strengthen their control. It's the same with the Chrome browser that they eventually used to push MV3 and tried to push WEI.

Honestly? I feel that this could be their way of pushing WEI again through the back door, and I am concerned that unlike WEI, this seems to barely get any buzz or pushback from the community.

> At a high level, the DBSC API lets a server start a new session with a specific browser on a device. When the browser starts a new session, it creates a new public/private key pair locally on the device, and uses the operating system to safely store the private key in a way that makes it hard to export. Chrome will use facilities such as Trusted Platform Modules (TPMs) for key protection, which are becoming more commonplace and are required for Windows 11, and we are looking at supporting software-isolated solutions as well.

Seems like a cat-and-mouse game never ends, and now they want to include hardware mingling with cookies - go adtech, go!

If your user env is compromised its too late; just a matter of time before that vector gets exploited.

I dont want the same convince as other people choose to have; just force log me off of sites after a time limit, stop tracking me and give me my internet without javascript back (imagine going back to 2000 and suggesting to stop using Flash, lol)

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.

> If your user env is compromised its too late

How to recover from a "my env was compromised" situation? Do you recommend just say good bye to this world and commit suicide?

If not, this change makes the recovery easier: I just need to (worst case) destroy the compromised device and I can be confident that nobody is hoarding a valid credential to my online banking account which they may choose to empty (again) years later.

> How to recover from a "my env was compromised" situation

depends on the scope of the compromise, its an open ended question with lots of rabbit holes dependent on backups and other stuff.

but as others mentioned: logging out of all sessions is a good start from the <bank, ect> side... people should be logging out of sessions anyways when not logged on a particular sites webui.

we are at a fun time when browsers have too much access (and javascript <reminds me of Flash>) to the host system that they are themselves are the OS (its been this way for many years)... the bigger issue are the websites that dont auto logoff, that have really poor password compliance, and even worse encryption of their own systems. a compromised system also means your password vault is compromised too given that it is in the same env. a more complex solution would be to have your keepassdx on an internet-less system and your browser on another system where a user logs off explicitly, if not automatically). then syncing bookmarks and play-time and sites-ive-visited can be less of a 'my whole account session' got compromised

Log into the bank and click the "log out of all sessions" to invalidate all cookies. Or if an attacker changed your credentials walk into the back and have a banker do it and then have the show/reverse all changes and transactions the attacker made. If the option does not exist, demand they add it or you and your money will go to another bank. Not all websites have this option but they would if enough customers demanded it.

Not all applications provide users with the option to log out of all sessions.

Web Applications today, could do several things without the help of Google to make cookies more difficult to be stolen but they don't.

This looks like a tool for Google/Alphabet to use to improve ads or make it more difficult to use unapproved browsers under the guise of 'privacy'.

An astroturf feature not unlike ManifestV3.

Call me insane but I feel like that's just a rebrand of WEI or will evolve into WEI. Just like everyone hated FLoC and when Google introduced Privacy Sandbox everyone was silent about it.

This is going to lock down the web considerably. A lot of tools like those that download videos rely on being able to export your browser cookies and use them to establish a session in your cli tool.

Just makes it more annoying to implement. Your locally running CLI tool will still have access to the local TPM the browser used: in other words, the CLI tool can implement the necessary parts of the browser.

Reply on news.ycombinator.com