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?
> 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.
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".
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
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.
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
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.
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.
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.
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.
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.
No I just won't use your crap. The value proposition is already marginal almost all the time, this tips over to "absolutely not, fuck off" territory.
>If you want to write your friends a message
Then I will use email as I do today. It works, it's universal, and it's free of this kind of bullshit (which is why they push everyone to use other things.) I even went on a date last weekend I set up over email (and it's far from the first.)
I am with you all the way. But the amount of people that only use whatsapp for example in my daily life is staggering. I don't think the good guys are gonna win this one in the end.
Sometimes I try to imagine a future societal split akin to the Amish. Not as a religious group, but as a social movement eschewing these overbearing IT products and services. A rejection of this "attention" or "dopamine" exploitation market.
It is hard not to take a cynical view, that such dissenters will be pursued aggressively by a system that demands conformity. I do recognize the quasi-fascist leanings in modern consumer IT products and their backers.
But, even if tolerated by this larger IT-bound society, can this sort of IT abstention be carried on long enough and made feasible for different age groups and personality types? Can it be the basis for a sustainable, multi-generation subculture? Or is it more ephemeral, a phase someone might go through, like retirement to a quiet cottage...
I personally inherited most of my understanding of ethics and engineering principals from my father and know a number of people who feel similarly. I think there is potential for the free software movement to persist in the way the Amish have but it's going to have to be combined with both an actual religion and particular reality.
Perhaps you could come up with some sort of argument for it from Christianity and start a Christian sect/denomination from it.
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.
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.
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.
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 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.
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.
~~~~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?
> 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.
Dude; please stop spamming misinformation, this was already debunked in previous commentary you saw and responded to, showing that the website never sees the raw TPM data at any stage under this proposal.
Session cookies have zero correlation to fingerprinting.
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.
> You all don't understand how any of this tech works but you think you do.
We do; and it is specifically called out in the spec that the certificate chain is not submitted, due to the potential for overpowered fingerprinting. As such, this battle, should they make a move to change that, needs to be fought a different day. Fighting against hypotheticals is pointless.
Edit: For the pedantic, fighting against hypothetical things that they could do if they invented something that doesn't exist right now, is pointless.
Edit 2: You can't boil a frog without ecosystem cooperation. The internet isn't going to bow to inconsistent adoption. They already made it clear with WEI they have no interest.
No, fighting against things that have already happened is pointless. We only ever fight against hypotheticals. We fight to avoid something happening that has not happened.
> Edit: For the pedantic, fighting against hypothetical things that they could do if they invented something that doesn't exist right now, is pointless.
But it ALREADY EXISTS on Android[0] and has been proposed by google to be added to chrome before [1]. They are OBVIOUSLY using a boil the frog approach here like forcing android devs to register to sideload [2]. This is obviously designed to slowly roll out these checks small steps at a time. To not see that is to be willingly ignorant.
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.
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?
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.
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.
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.
"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!)
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?
reply