Google bod wants cookies to crumble and be remade into something more secure

A key member of the Google Chrome security team has proposed the death of cookies to be replaced with secure HTTP tokens.

This week Mike West posted his "not-fully-baked" idea on GitHub and asked for comments. "This isn't a proposal that's well thought out, and stamped solidly with the Google Seal of Approval," he warns. "It's a collection of interesting ideas for discussion, nothing more, nothing less."

So far, people are largely receptive to the idea while pointing to the complexities that exist in trying to replace something that has become an everyday part of online interaction.

Broadly, West's idea would be to slowly deprecate the ubiquitous snippets of code that allow websites to track a user - and so provide valuable services like allowing you add products to a cart and check out later - by introducing "client-controlled, origin-bound, HTTPS-only session identifier for network-level state management."

Or, in other words, tracking code would be controlled by a browser through a secure HTTP header (a unique 256-bit value) passed along when someone visits a given website, rather than held on the server.

While the result would be effectively the same, West argues that this approach would create a new default where user tracking has security and privacy built in. He points out that although there are several standards that would allow cookies as they currently work to be more secure, "adoption is low to non-existent."

By sticking a session-identifier into HTTPS, it would associate it with a specific domain name, increasing security. And by running it through a secure, encrypted, protocol, the identifier could not be sent in plaintext, making monitoring harder.

Restrictions on HTTP header length would limit how much personal information can be stored within such a cookie and so reduce the likelihood of your sensitive information being grabbed.

Stamp on Java

This style of cookie would not be available to JavaScript, which could have significant security advantages, including making it much harder to use stolen tokens to access a website pretending to be someone else. "Including a timestamp in the request might reduce that capability even further by reducing the window for pure replay attacks," West notes.

"It is both more elegant and more respectful of users' resources to migrate towards browser-controlled session identifiers, rather than oodles of key-value pairs set by the server."

The idea is currently only rolling around browser nerds and several people have pointed out that large companies like Facebook, which rely on cookies to give them endless access to user data, are unlikely to be excited about the idea of restrictions on what they can currently do.

It would be possible to create multiple different tokens over HTTPS – which would allow for expansion on what can be done - but then you could up in the situation where dozens of tokens are created and a new browser headache is born.

Assuming everyone agreed that this more-secure approach was worth going to all the trouble to create and implement, the question would then be: what happens to the billions of cookies that websites constantly use to provide useful user interaction?

People would move "slowly and gradually" to cookie 2.0, West reasons. You could run the two side-by-side while developers slowly move across to the new HTTP-cookie and then, "eventually you could imagine giving developers the ability to migrate completely, turning cookies off for their sites entirely."

Not sold

Prodded about how this would work with sub-domains, West admitted that his proposal had sparked the same question and concern internally.

"Google relies heavily on 'http://accounts.google.com' to maintain state across sub-domains," he acknowledged. "The sign-in team is not at all sold on this, for reasonable reasons." But, he says, it's doable even if it would "be a lot of work."

There is a lot more detail on West's proposal in his write-up on GitHub and he has been responding to dozens of questions, queries and criticisms on his Twitter account.

As to whether the idea has legs, we'll have to see. There is a notable shift among internet engineers to introduce more security online, with Google heavily pushing HTTPS, certificate authorities tightening up their rules, and the IETF officially approving TLS 1.3 this month. It's not hard to see how a default improvement in cookie security could gain a lot of attention if it was seen to be viable. ®