Google bakes new cookie strategy that will leave crooks with a bad taste Google reckons that cookie theft is a problem for users, and is seeking to address it with a mechanism to tie authentication data to a specific device, rendering any stolen cookies useless. Cookies are still widely used by websites, which get the browser to save information on a session locally to a small file (the cookie) …
The Microsoft Edge browser is Chrome...
Also, how is Chrome going to get write access to the TPM? Am I going to have to repeatedly lock and unlock the TPM to allow Chrome (which is configured to clear the cache on exit) to create a new keypair every time its restarted?
Additionally, for those users who don't clear their cache on exit, won't having a single for-Chome public/private key pair make user tracking so much easier?
Sounds to me like this is the LAST thing any sane person would want.
Edge is based on Chromium; Chrome itself contains all kinds of Google-specific stuff.
I'm not 100% confident but the implementation looks like a reasonable mitigation against session-stealing. I don't think that a single pair of keys is the idea: amongst other things, this would make tracking a lot easier. But also, if the validation is happening on the client then public keys are only exposed when the cookie is first set up. However, it might still be possible to cause trouble if the public key can be intercepted and, therefore, reused at the right moment.
And, if the implementation degrades reasonably, it can be provided when supported, dropping down to other mechanisms when its not.
There's a little more detail here.
The proposal is essentially that at the point at which a user "logs in" (or equivalent) to a website (it doesn't apply to unauthenticated sessions) the browser is prompted to generate a private key which is used to secure session cookies. That private key is then destroyed when the user "logs out" (or equivalent) or when the browser quits. Since the private key isn't reused, then there shouldn't be a privacy issue - however, since the key is tied to a "log in", then you're not talking about an anonymous user in any case so that's all really moot.
There's nothing inherently that requires a TPM - it would clearly have some potential benefit simply using a software key vault of some kind, but with greater risk of malware exfiltrating the keys and transparently continuing the session on another device. Though TPMs are not quite as inflexible as might be supposed by the time the OS has built an environment around them - assuming you have one to hand.
I think the big problem with the Google proposal is that it's essentially a hack: it requires the browser to periodically refresh its credentials (to prove it still has the private key) by making an http request to a specific URL associated with the application. Unlike, for example, Token Binding which is a proposed extension to TLS that is transaparent in that it doesn't depend on upper-layer application behaviour. The somewhat questionable justification for Google's approach is that in typical web application infrastructures, the security context (TLS connection) has been stripped by some border device and is unavailable to the web application code. And justifying your security hack on the basis that you junked all the security data you had at the earliest possible moment is very typical of modern practice, but I can't help feeling a better solution might be available.
This is a good explanation but tying e2e credentials to TLS isn't something that would work on the modern Internet. It'd require the Application layer and HTTP to have information from and interact with the TLS session. That would make all cloud-based load balancers that terminate TLS (most of the Internet nowadays) incompatible. It also gets tricky to handle mid-session where the session cookie is actually being created or destroyed.
Overall, binding cookies to a device is certainly the way to go. Even without a TPM, having a device-specific storage (like a service in Linux running as a different user) would be a big leap. And for the cases where you can't trust the local system, you'll need a TPM-like solution.
Termination proxies already communicate that sort of information with "X-Forwarded-For", "X-Forwarded-Host", and "X-Forwarded-Proto" HTTP headers. I can't imagine it difficult to have one more header that carries some session data. Or perhaps the proxy can be in charge of confirming sessions on behalf of the application, which only needs to know who a user is after authentication.
I think that readers will have noticed that I used the word "modern" pejoratively and that you used it in a more positive - or at least neutral - way.
The explanation is perhaps that, being (very) old, I've heard similar arguments made a lot - we are where we are and we need to get the job done. But next year we'll be somewhere else and the point of standards is to lead us towards a stable and rational objective, not to codify current practice in a way that leads to stagnation or, worse, continuous and directionless change according to the latest whim. The architecture should specify how it ideally would work in the long run, before considering the transitional arrangements - which are undeniably necessary - to deal with present reality. However, here, at least in my estimation, we seem to have started with present reality and worked backwards. It will do for now and another proposal will come along later. It must make for an exhausting life.
Great additional explanation. I think the privacy concerns are related to other sites attempting to get the device's and hence user's public key for tracking purposes, so single use is reasonable.
I agree that better solutions might be possible but think we should welcome the idea and potential proof of concept: it's certainly an improvement on the current situation and the rising risk.
Session ID cookies (mostly) operate in the exact opposite way, they provide a key to a server side session store, and are the most common way of providing a user login. You can use client side sessions, where the session data is encoded and stored in a cookie, but this has limits on state size, and the state is visible to the end user - they can't modify the state, as it will be signed/protected by hashing the encoded session data combined with a server side secret.
http was traditionally stateless to save resources: connections were never intended to be persistent. However, as soon as logging in was required, persistence was required and we got sessions. These don't have to be secured by cookies, but the alternatives: session ids in the URL were even easier to steal, especially before everything was encrypted.
http/2 isn't really stateless any more as connections are often persistent (servers are much, much beefier and the protocol has been adapted to suit multiple requests from the same device) but the rest of the stack is still required and as more and more "important stuff" goes over http, the desire to obtain credentials for nefarious tasks rises.
Didn't we read a bunch of articles over the last few years about how Google was getting rid of cookies entirely?
I mean obviously Google wasn't going to stop tracking you, but I thought they were trying to fool people with the claims about eliminating cookies. Did enough people see through that they have abandoned the "we are eliminating cookies" and are now saying "we are bringing you Cookies 2.0" - now cryptographically linked to your device so even better at personally identifying you! But don't worry, that's for your own good *wink wink*
By all means go after Google for being a massive slurper of personal data but don't let this blind you to what it does get right. Google has a pretty good record on security and was proactive on it years before it became fashionable and it took a lot of flak for its project zero, which has, however, now become standard. This may all be good business including polishing its reputation but I also think they're aware of the potential financial risk when systems become compromised: these could be customers losing data but it could also apply to its own employees.
When I was a Google (2015-6), I would definitely NOT agree that they were good at security. Their culture was strongly built around the free flow of information, and getting GCP up to outside corporate standards was a huge and painful undertaking.
It is true that Google has a decent record regarding application security--when it suits them. But they have clearly prioritized the inbound data flow just like Adobe, and this is why Chrome will continue to be a rich source of CVEs.
Unless I am totally misunderstanding this issue there seems to me to be a very simple way to bypass this sort of "hack" - one that I have used for a number of years on some of the websites I operate...
I tie some visitor cookies (specifically related to those that are sellers [the site members] or buyers) to the IP address of the visitor when the visit is initiated - if the IP address changes during the interaction the visitor is advised that an error occurred and to re-try and the cookie is reset...
So far no complaints
So am I really dumb on relying on such an idea, or have I missed the point?
or, how to fail forever. Goog is an evil greed driven company. yeah, everyone knows it. so Lets not let them dictate what tech people use.
It's long past time to get away from evil companies spying. Letting them dictate what tech people use only "ensures" that data will be taken from people.
If this crap keeps up, internet will become like 8-track tapes, to annoying to use.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
