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
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.
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.
Readit News
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.
Dead Comment
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.