Rethinking cookies

One complaint I’ve heard about the HTTP/2 spec is that it doesn’t introduce a better persistence mechanism than cookies. While I think it’s not the place for a new version of the protocol to demand people rearchitect the way their apps work, I do think it’s worth throwing around ideas for new headers that could replace them.

What I’d like to see, as an alternative cookies, are UUIDs generated and managed per-domain (as in “same domain rules” domain) by the user agent, that are included in headers with each (secure) request: one for the current browser session, one for the device across sessions, and another class that could be persisted via another mechanism (ie. Chrome Sync) across devices.

Users could reset these at any time via the UX facilities they have for managing cookies right now (eg. clicking the icon in the address bar in Chrome). They could also choose to opt out of them on sites they don’t want to be tracked on, or to only explicitly enable them if they’re paranoid (the way that browsers like Lynx prompt for every cookie by default).

These headers could also be disabled for any cross-domain content so as to thwart framejacking and tracking (and enabled via request for explicit user approval in situations where they’re actually necessary - hence “Google AdWords wants to see your activity on this site” could be consciously refused by the user).

The idea of this header would be to initially provide a more appetizing alternative to cookies that developers could gravitate toward, leading to better UX around user sessions (since there wouldn’t be the inbuilt assumptions around support the way there are for cookies). As more of the web would move toward supporting one-way tokens like this, the old defaults around cookies could be deprecated and retired, the same way as how built-in pop-up blocking across all the major browsers made popup-based navigation wane to near-nonexistence over the course of several years (the idea being you would choose to “Accept cookies” about as frequently as you’d pick “Allow popups” today).

To simplify this, I would reduce it to just the cross-session “device” UUID. The notion of a “session” is increasingly meaningless in the modern resume-on-start ecosystem, and cross-device syncing could be handled in any number of better ways (having the UA offer to sync the UUIDs, reading identity via something like Persona, or associating on the backend after third party OAuth verification).

I was thinking there might be call to have a separate UUID, with the same persistence semantics, exposed to scripts instead of requests (as a different UUID, so the one on requests is effectively httpOnly). However, I’m not sure if there’s really any call for scripts to have access to a UUID like this - non-httponly cookies are essentially only useful for slumming localStorage, AFAIK.

The central problem here is how to encourage the transition. You say it’s a “more appetising alternative to cookies” – how is it more attractive to Web sites, as compared to cookies?

If we could find a good answer to that, I think that it’d be possible to supplant cookies; e.g., by having browsers only send this new header when no cookies are stored for the origin.

And, I do think that there are some possibilities, because there’s some information that cookies don’t capture about user sessions (as you imply).

However, making something more attractive than cookies to Web sites means that it’ll need to be as useful as cookies are now for them – including for things like SSO, and yes, ad tracking.

If they don’t support that, ad networks et al won’t migrate to them, and will stay on cookies. Even if we find a way to force them to stop using cross-domain cookies and use a browser-generated, origin-scoped session ID instead, sites will likely find a way to pass identity around on the back end, making the privacy impact even more opaque than it is.

That’s arguably a worse outcome than where we currently are – i.e., if the endgame for this is both cookies and this new header being widely deployed, it’s not a good outcome for privacy or end users. I’m concerned that without the ‘carrot’ for getting sites to move over en masse, it’s going to be too difficult to introduce your ‘stick’ of requiring explicit opt-in to use cookies; too many sites will want to stay on them (even in the long run).

Have either of you seen the Origin-Bound Cert and Channel-Bound Cookies specs?

http://www.browserauth.net/origin-bound-certificates

http://www.browserauth.net/channel-bound-cookies

Its almost exactly what you described.

It originated from Google and they are actually using it in production. Chrome is the only browser that implements it and Google properties are already using it. Look around in your Chrome cookies, you see some “Channel ID” super cookies, thats them!

There doesn’t seem to be any open source implementations available for Apache or nginx. As far as I can tell, Google has the only closed sourced version baked into their “gws” (Google Web Server).

I think its pretty neat and would totally consider rolling it out too if 1) there was an open implementation and 2) there was some indicator Google is still serious about it and its not going to be abandoned any minute.

They started on an IETF draft a few years ago now, but it didn’t seem like it went anywhere. https://tools.ietf.org/html/draft-balfanz-tls-obc-00

Yep - they’re interesting, but specific to Chrome (for now).

See also: https://datatracker.ietf.org/wg/tokbind/charter/ … which is likely to be chartered soon to work on things that might be interesting…

Has there been any progress on that? This “token binding” thing sounds interesting, but it also sounds really technical and over my head (and my rule of thumb is, if it goes over my head, it will go over most dev’s heads).

I’m thinking about drafting up a proposal for some kind of Consensual Tracking Community Group, for pursuing a browser UX that can let us migrate to world where tracking the user with their consent is non-intrusive, but tracking it without their consent is a thing of the past.