undefined | Better HN

0 pointscomex13y ago0 comments

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

0 comments

phkamp13y ago

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.

comexOP13y ago

> 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?)

phkamp13y ago

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

comexOP13y ago

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.

j / k navigate · click thread line to collapse