| > 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. |
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.