Hacker News Reader

Comment by joosters | Hacker News Reader

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier."

In fact there's no need for this to be tied in with HTTP/2.0 at all. Alternate systems could be designed without regard to HTTP/1.x or HTTP/2.y, they just have to agree on some headers to use and when to set them.

Making these kind of changes as part of a new version of HTTP would just be bloat on an already bloated spec, it is actually a good thing that the spec writers did not touch this!

View on HN

> there's no need for this to be tied in with HTTP/2.0 at all.

Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.

This is not equivalent to cookies.

Cookies allow you to specify arbitrary data, not just a session ID, so you can set preferences without having to hit a database or even running a completely static page, using javascript to read the settings.

Cookies as they are now already allow you to control persistence. You can edit or delete them however you wish.

Except that deleting/not allowing cookies will make most of the things we use everyday unusable. Including this website.

Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).

I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.

It's really very simple:

Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits.

In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie.

If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session.

If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you.

Of course this can be abused, but not nearly as much as cookies are abused today.

But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.

It also forces the session to be tracked on the server. Many apps use cookies to keep the session in the browser. Maybe deprecating the document.cookie API so that people move to local storage, is a good first step?

More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

(Without being pedantic) are you aware of MinimaLT? It is really interesting technology (UDP).

Seems like anything a server could do via cookies, they could also do via your client-generated session id.

Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id.

If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.

Well, yeah, for a basic implementation, it's rather easy to track like that. What about a system where the unique id returned is based on a random value hashed with the domain name of the window? Then third party trackers would get a different id from you on each site, but your sessions would be static on the site.

True it would make it difficult to do third-party tracking across multiple sites (unless there was server-side information connecting your accounts, like an email address). And leaving aside browser fingerprinting.

That could also just by achieved by disallowing third party cookies though - feels on the cusp of being a browser implementation problem (just stop allowing third party cookies).

This is the link to MinimaLT (it runs on top of UDP instead of TCP). As of today I haven't seen an implementation and MinimaLT being a paper there are some ambiguous parts, but overall this looks like a really well defined spec. It tackles at least the cookie issue. It supports tunneling and it deals with DOS. The other real benefit is that it is RPC based, which means that the protocol is easy to extend (think about NFS and SSH alternatives) and maybe it could be the foundation of a new HTTP. AFAIK it doesn't deal with the CA certs / trust issue.

http://www.ethos-os.org/~solworth/minimalt-20131031.pdf

Reply on news.ycombinator.com