A few years ago I would read this headline with hope and excitement about technological innovation.
Right now, I am apprehensive about anything Google related. Even about anything big tech related. How is this going to be used to limit our rights and track all our movements?
drob518 · 14d ago
It turns out Google really is evil. Surprise!
prasadjoglekar · 14d ago
The first sentence
> HTTP cookies were never intended for session management
Seems odd. IIRC that's exactly what they were meant for. State management for http which is stateless. Am I missing some history here?
pfortuny · 14d ago
> This document specifies a way to create a stateful session with
Hypertext Transfer Protocol (HTTP) requests and responses. It
describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
carry state information between participating origin servers and user
agents. The method described here differs from Netscape's Cookie
proposal [Netscape], but it can interoperate with HTTP/1.0 user
agents that use Netscape's method. (See the HISTORICAL section.)
RFC 2965, make of it what you want but I agree with you. Actually, RFC 2109 is even older (1997) and says more or less the same.
stephendause · 14d ago
I could be wrong, but I believe the author is referring to cookies being used for session authentication as opposed to general session management.
TheRealPomax · 14d ago
That's still exactly what they they were invented, though. The very first example in RFC2109 is literally for tying a session to a login.
The "abstract idea" of a cookie is an identifier that it lets a server consider requests within a larger series of requests by the same person, but the fact that it can do that at all also meant that it solved the whole "how do we know whether this user is logged in without every page request after login needing to be a POST that includes the user's name and password again".
echelon · 14d ago
I'm starting to look at every technology change Google makes as a way for them to entrench their moat.
The faster we get an antitrust breakup of Google from Chrome and Android, the better.
alexbilbie · 14d ago
There’s going to be a lot of LinkedIn scrapers and tools that are going to stop working if LinkedIn adopt this - a lot of these tools work off particular session cookies you share with them
odie5533 · 14d ago
If it's your TPM, the tools should be able to be authorized for signing too.
The article claims this is based on Token Binding, but skimming the W3 spec it seems to be something entirely different and not at all to be based on or related to TLS Token Binding (with an integration already envisaged by the WebAuthN spec). TB doesn't need or rely on a TPM at all, it conceptually just ties bearer tokens to a key which is (re-)used across TLS sessions; for upper layers this is transparent, but for attackers it makes it much harder to use exfiltrated tokens.
However, DBSC as an API and protocol is similarly agnostic about key storage. There is no attestation and the User Agent is fully responsible for selecting key storage that provides the best protection.
speed_spread · 14d ago
Funny how we're going back to AOL times: fenced off network, pay-to-play. We've required ISPs to play fair though net neutrality only to have similar barriers put in place a decade later by upstream software incumbents.
No comments yet
nixgeek · 14d ago
I think Microsoft has also been working on this and protected resources using Conditional Access can enforce a requirement for DBT?
The spec doesn't say where you store the key material, but you could reasonably put it in a TPM.
jawns · 14d ago
We're still in the infancy of agentic AI, but I imagine that in the next few years, it's going to be more important to be able to grant an agent your credentials to perform operations on your behalf. Basically, you want the agent to be able to do all the same things you can do. But perhaps the agent doesn't live on your local device. I'm not saying that DBSC isn't beneficial, but I think we also need to be thinking of ways to grant AI agents permissions that used to be solely tied to the user's session.
dlojudice · 14d ago
I think the DBSC is on the right direction but while it generates separate keys per session to prevent cross-session tracking (Google's ultimate ad dream), the spec acknowledges a critical vulnerability: malicious sites can collaborate by attempting to guess public keys until they find matches, creating persistent cross-site user identifiers, essentially weaponizing the security feature into the ultimate tracking system that survives cookie deletion and VPN usage
Vecr · 14d ago
How long are the public keys? >160 bits and that's futile.
yalogin · 14d ago
If TPM is used then the regular session cookies are also secure, just in a different way. One can use hardware based attestation to tie the session token/cookie to the device and so they cannot be stolen or forged.
DBSC will run into all the same problems on platforms that don’t support TPMs. Not sure how this is changing the landscape. It’s just another implementation of the same thing.
aleksejs · 14d ago
I'm not sure I follow your point: how would a web service provider use a user's TPM in a pre-DBSC world? "Use hardware based attestation to tie the session token/cookie to the device" is pretty much exactly what DBSC does.
DBSC is intended to be deployed opportunistically alongside regular cookies, so users on devices without TPMs just won't benefit from the additional protections that DBSC provides.
mathiaspoint · 14d ago
Unless you're paying me a lot of money (and even then) I WILL NOT MAINTAIN AN HSM FOR YOUR SERVICE. PLEASE FUCK OFF.
If you cared about security you would let me authenticate with ssh key signatures. GitHub does this, if you can manage to talk to an HSM you can manage to talk to the openssh agent.
throwawayffffas · 14d ago
This so much, it's all about locking people to their hardware and walled gardens.
IlikeKitties · 14d ago
[flagged]
dang · 14d ago
Could you please stop posting flamebait and snark? Your account has unfortunately been doing this repeatedly. It's not what this site is for, and destroys what it is for.
You're of course welcome to make your substantive points more thoughtfully.
IlikeKitties · 14d ago
You know what dang, I'll genuinely consider it.
I truly believe that we'll see a world where everything requires remote attestation and corporate approved devices within the next few years. It's a nightmare scenario for me and I consider it inevitable. I just don't have much more than sad cynicism left since it seems to become worse every day.
dang · 14d ago
Your genuine consideration is appreciated!
I hear you about this issue (corporate control over devices, let's call it) and of course a large segment of the community agrees with you. Howwever, the moderation point here isn't about that; it's about a style of commenting that we're trying to avoid here. Your account has been posting in that style on unrelated issues too, so I think this is independent of the specific content.
jsnell · 14d ago
This has no connection with reality. This is not an attestation mechanism, and can't be used as one.
IlikeKitties · 14d ago
Yes it absolutely is and will be used as such, this is EXACTLY how google play remote attestation works and a necessary building block for doing it in the browser. It is the exact reason why microsoft and google are pushing for tpms in windows 11 and it's already a reality on android and every grapheneos user knows the pain[0] and is the absolutely logical next step.
I read that not as a claim that this is an attestation mechanism, but that this is another step towards that. Given that Google has previously discussed implementing the Web Integrity API, it's not so large a leap as to be dismissed as disconnected from reality.
snickerdoodle12 · 14d ago
It's clearly a link in the chain.
jeffbee · 14d ago
Yes but the commenter has referred to you as a stock animal, therefore he automatically wins the debate. Sorry, I don't make the rules.
chaz6 · 14d ago
I am glad I got to experience the internet before this. It seems sadly inevitable. What was once built by and for the people has been taken over by the interests of the rich and powerful.
odie5533 · 14d ago
What negative effects are you thinking DBSC will cause?
IlikeKitties · 14d ago
The very next step they will take is that they will only give devices session credentials that pass remote attestation, preferably to the browser level. Than you won't be able to use alternative clients or extension google doesn't deem acceptable.
tantalor · 14d ago
(engaging in good faith...)
What's preventing alternative clients from doing that?
No comments yet
nixgeek · 14d ago
You seem to spend most of your time on HN saying the cattle are meeting the butcher, or saying fsck responsible disclosure, or other hot takes.
No comments yet
Vecr · 14d ago
You can run a software TPM if you browse within a VM.
kbaker · 14d ago
~~~~But your VM TPM won't be signed during manufacturing by a trusted root. No attestation.~~~~
OK I take it back, privacy is one of their specified goals:
> Note that the certificate chain for the TPM is never sent to the server. This would allow very precise device fingerprinting, contrary to our privacy goals. Servers will only be able to confirm that the browser still has access to the corresponding private key.
However I still wonder why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side? Seems like this would accomplish a similar goal?
arnarbi · 14d ago
> why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side
That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.
And that Software TPM has whos vendor endorsement keys exactly? Ah yes, ones that google won't consider valid.
gjsman-1000 · 14d ago
Well, it's a good thing Device Bound Session Credentials (DBSC) as proposed here has no way to actually send said endorsement key anywhere; rending the objection irrelevant. The TPM is only for secure storage as verified by the browser itself, not the website being visited.
No comments yet
UltraSane · 14d ago
This inexplicable overreaction to genuinely valuable security improvements is getting ridiculous. Computer security is a complete dumpster fire right now and we need things like this.
speed_spread · 14d ago
> valuable security improvements
Valuable to who, exactly?
Analemma_ · 14d ago
To everyone who has ever had session creds stolen? Right now any malware which can read your disk has a gigantic backdoor around MFA, do you not find that a problem?
v3xro · 14d ago
If you have malware that can read your disk, then you have bigger issues than MFA?
In other words - focus on solving the real issue (ability to give more fine-grained permissions to programs) rather than restricting the ability of users to do what they want with credentials they already have on hardware they control.
UltraSane · 14d ago
To everyone who uses computers.
pessimizer · 14d ago
> we need things like this.
Speak for yourself, Kemosabe.
odie5533 · 14d ago
I hope it catches on! Though they suggest storing the signing keys in TPM which is ideal, even storing them locally in the browser in an unextractable manner would be enough to prevent session hijacking.
Retr0id · 14d ago
"unextractable" from the perspective of the JS-facing APIs does not necessarily mean unextractable by local malware (unless it's backed by something like a TPM!)
odie5533 · 13d ago
Most session hijacking is via JavaScript, so even malware-extractable browser-TPM would help a lot!
Retr0id · 13d ago
You can use js-nonextractable keys for auth today, no new specs needed.
grim_io · 14d ago
One man's session hijacking is another man's unofficial third party client support.
Garvi · 14d ago
This will break and fracture the web. Unfortunately many here have much to lose by criticizing google. I have just spent 8 hours today updating my apps on the google play store, answering business emails on my google email account and updating customer tracking data on google analytics and updating their google ads.
If they decide to make an example out of me, to teach the rest of you how to behave, I am screwed. I guess that's the "freedom" you US based folks are talking about. This has already been affecting the discourse on sites like HN for a while.
mathiaspoint · 14d ago
If you get creative and find a way to sell yourself into slavery despite us making that nominally illegal there's very little we can do to help you.
Right now, I am apprehensive about anything Google related. Even about anything big tech related. How is this going to be used to limit our rights and track all our movements?
> HTTP cookies were never intended for session management
Seems odd. IIRC that's exactly what they were meant for. State management for http which is stateless. Am I missing some history here?
RFC 2965, make of it what you want but I agree with you. Actually, RFC 2109 is even older (1997) and says more or less the same.
The "abstract idea" of a cookie is an identifier that it lets a server consider requests within a larger series of requests by the same person, but the fact that it can do that at all also meant that it solved the whole "how do we know whether this user is logged in without every page request after login needing to be a POST that includes the user's name and password again".
The faster we get an antitrust breakup of Google from Chrome and Android, the better.
Defending against account takeovers with passkeys and DBSC (11 points, 1 month ago) https://news.ycombinator.com/item?id=44725402
Chrome Origin Trial: Device Bound Session Credentials (85 points, 4 months ago, 80 comments) https://news.ycombinator.com/item?id=43865379
Device Bound Session Credentials Explainer (14 points, 2024, 5 comments) https://news.ycombinator.com/item?id=39926961
However, DBSC as an API and protocol is similarly agnostic about key storage. There is no attestation and the User Agent is fully responsible for selecting key storage that provides the best protection.
No comments yet
https://learn.microsoft.com/en-us/entra/msal/javascript/brow...
https://datatracker.ietf.org/doc/html/rfc9449
The spec doesn't say where you store the key material, but you could reasonably put it in a TPM.
DBSC will run into all the same problems on platforms that don’t support TPMs. Not sure how this is changing the landscape. It’s just another implementation of the same thing.
DBSC is intended to be deployed opportunistically alongside regular cookies, so users on devices without TPMs just won't benefit from the additional protections that DBSC provides.
If you cared about security you would let me authenticate with ssh key signatures. GitHub does this, if you can manage to talk to an HSM you can manage to talk to the openssh agent.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
You're of course welcome to make your substantive points more thoughtfully.
I truly believe that we'll see a world where everything requires remote attestation and corporate approved devices within the next few years. It's a nightmare scenario for me and I consider it inevitable. I just don't have much more than sad cynicism left since it seems to become worse every day.
I hear you about this issue (corporate control over devices, let's call it) and of course a large segment of the community agrees with you. Howwever, the moderation point here isn't about that; it's about a style of commenting that we're trying to avoid here. Your account has been posting in that style on unrelated issues too, so I think this is independent of the specific content.
[0] https://grapheneos.org/articles/attestation-compatibility-gu...
No comments yet
What's preventing alternative clients from doing that?
No comments yet
No comments yet
OK I take it back, privacy is one of their specified goals:
> Note that the certificate chain for the TPM is never sent to the server. This would allow very precise device fingerprinting, contrary to our privacy goals. Servers will only be able to confirm that the browser still has access to the corresponding private key.
However I still wonder why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side? Seems like this would accomplish a similar goal?
That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.
Some more on this in the explainer: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...
No comments yet
Valuable to who, exactly?
In other words - focus on solving the real issue (ability to give more fine-grained permissions to programs) rather than restricting the ability of users to do what they want with credentials they already have on hardware they control.
Speak for yourself, Kemosabe.
If they decide to make an example out of me, to teach the rest of you how to behave, I am screwed. I guess that's the "freedom" you US based folks are talking about. This has already been affecting the discourse on sites like HN for a while.