[phkamp]

I agree that anybody with sufficient clue can and will use cookies as id only.

Unfortunately such people are evidently few and far between.

Banning cookies and having the client offer a session identifier instead solves many problems.

For starters, it stores the data where it belongs: On the server, putting the cost of storage and protection where it belongs too.

This is a win for privacy, as you will know if you have ever taken the time to actually examine the cookies on your own machine.

Second, it allows the client+user to decide if it will issue anonymous (ie: ever-changing) session identifiers, as a public PC in a library should do, or issue a stable user-specific session-id, to get the convenience of being recognized by the server without constant re-authorization.

Today users don't have that choice, since they have no realistic way of knowing which cookies belongs to a particular website due to 3rd-party cookies and image-domain splitting etc.

Network-wise, we eliminate a lot of bytes to send and receive.

One of the major improvements SPDY has shown is getting the entire request into one packet (by deflating all the headers).

But the only reason HTTP requests don't fit in a single packet to begin with is cookies, get rid of cookies, and almost all requests fit inside the first MTU.

Finally, eliminating cookies improve caching opportunities, which will help both client and server side get a better web experience.

As for breaking the world: It won't happen.

It is trivial to write a module for apache which simulates cookies for old HTTP/1 web-apps: Simply store/look up the cookies in a local database table, indexed by the session-id the client provided.

I'm sure sysadmins will have concerns about the size of that table, but that is an improvement, today the cost is borne by the web-users.

[comex]

> This is a win for privacy, as you will know if you have ever taken the time to actually examine the cookies on your own machine.

Most of the cookies I've seen are some kind of hash.

> Second, it allows the client+user to decide if it will issue anonymous (ie: ever-changing) session identifiers, as a public PC in a library should do, or issue a stable user-specific session-id, to get the convenience of being recognized by the server without constant re-authorization.

> Today users don't have that choice, since they have no realistic way of knowing which cookies belongs to a particular website due to 3rd-party cookies and image-domain splitting etc.

I don't see how this makes sense - what's the difference?

Assuming that the session identifier is different between sites (if it's not, then the user has no option to "remove cookies" for a single domain without deauthenticating everywhere, and it's harder to determine which sites are tracking you):

- There will still be third party domains involved, since advertisers will still want to correlate traffic between domains;

- Sending a new session identifier with every request won't be practical, because you won't be able to log in, but users will be able to set their browsers to send a new identifier when the window is closed or whatever... just as they could currently configure their browser to clear cookies at that time.

Also, anyone who wants to abuse cookies can just use localStorage.

> But the only reason HTTP requests don't fit in a single packet to begin with is cookies, get rid of cookies, and almost all requests fit inside the first MTU.

Surely it's still useful to deflate things (user-agent...), though, and then what does it matter?

> Finally, eliminating cookies improve caching opportunities, which will help both client and server side get a better web experience.

How so? The server is perfectly justified in sending different content based on the session identifier, so wouldn't a proxy have to assume it would?

But if you want to say the result doesn't depend on cookies, can't you just set a Vary header?

> It is trivial to write a module for apache which simulates cookies for old HTTP/1 web-apps: Simply store/look up the cookies in a local database table, indexed by the session-id the client provided.

Eh... okay. This still breaks anything that uses JavaScript to interact with the cookies.

[phkamp]

The client/user-agent gets to control what session-id gets sent to which sites.

That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites.

That will make tracking and correlation of webusage much harder, which I really don't see a downside to.

Deflate is bad on its own, it is a DoS amplifier and it makes the job of load-balancers much more resource intensive, because they have to retain compression state for all connections and spend CPU and memory on the inflation.

The server is perfectly justified in customizing content, and we have a header for saying that is the case: Cache-Control.

The problem with cookies is that they disable caching of everything on the site, including favicon.ico and there is nothing the server can do about it, because the cookies are sent on all requests.

Javascript will also have access to the session-id.

[comex]

> That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites.

This is already possible, just give tabs their own cookie context by default. (Browsers don't make this the default, but they all have some variant of "incognito mode" already...)

> The problem with cookies is that they disable caching of everything on the site, including favicon.ico and there is nothing the server can do about it, because the cookies are sent on all requests.

I admit that I don't know much about HTTP caching, but I don't see why the Cookie header would inhibit caching. (Edit: Isn't the purpose of the Vary header to specify which request headers affected the result, including Cookie?)

[phkamp]

(probably pressing wrong reply link here ?)

Cookies are almost never mentioned in Vary: so all caches have to assume that the precense of cookies means non-cacheable.

[comex]

Hmm. That would indeed be an advantage of a new mechanism.

What I meant about JavaScript is that a server side cookie->session bridge for legacy code would not work in general because corresponding client side code sometimes expects to be able to see the cookies in document.cookie.

[cbr]

An identifier has privacy disadvantages over a cookie with the same duration. The least privacy you have is when the server has a unique identifier for you: then they can do whatever they want. With a cookie the site has an option to store only what they need, instead of something unique. For example if I'm running an a/b test I could do this with a cookie, setting it to "1" for half the users and "2" for the other half.

(I work on mod_pagespeed, and our experimental framework uses cookies this way: https://developers.google.com/speed/docs/mod_pagespeed/modul...)