undefined | Better HN

0 pointscomex13y ago0 comments

> Why must HTTP 2.x be backwards compatible with 1.x?

Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk...

> Cookies suck, from a technical

Agreed, but...

> and regulatory-compliance standpoint.

I don't understand this point. Surely the need for regulation of user tracking by websites doesn't depend on whether cookies or an equivalent mechanism are being used? If people start using Not Cookies(tm), they will be unregulated at first, but the law will be changed if the effect is the same.

Edit: Similarly, any protocol that gives a website a persistent identity token without its explicitly requesting one is a bad idea - cookies do provide a modicum of visibility to the user regarding who's tracking them. Not sure exactly what Kamp is proposing.

> Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal and American Express accounts. Both sites keep creating unique cookies on every login until there are so many that they pass their own web servers' max header length limits.

Hah, no you won't. I strongly suspect legacy codebases will remain on HTTP/1.1 approximately forever, at least if 2.0 is backwards incompatible.

0 comments

jasonwatkinspdx13y ago

If you would bother to read the full thread as well as PHK's position proposal you'd see that removing cookies brings more than a tiny benefit. The overall flavor of his proposal is to reify a concept of session and by that eliminate redundant communication. At the same time we get substantial wins in security.

comexOP13y ago

You can add a concept of session without removing cookies, which are trivial to keep supporting since, as I mentioned, browsers will have to support cookies for legacy sites for a long time anyway.

I doubt the security argument amounts to much, considering that there are few sites with cookie-based vulnerabilities, it's long been trivially easy ($_SESSION in PHP) for any site to use identifiers as cookies, and many of the sites that are vulnerable are the kind of old-fashioned things that will never be upgraded anyway.

jasonwatkinspdx13y ago

Once you have a concept of a session unique nonce, cookies are needless. Browsers can implement a locally encrypted resumption store where the user entered entropy never touches the network to resume a session on the same machine. Resuming a session on a new machine could use 2 factor auth with fallback one time capabilities. That's big, doubly so given the clear historical trends in users ability to memorize entropy and the likelihood of hashed password database disclosure.

What you need to understand, is that we can get rid of cookies, live in a more secure world, and give up nothing. The only thing holding us back is unwillingness to understand the underlying issues and fear that we stand to lose something by advocating change.

On top of that, by standardizing on a nonce we avoid all cookie request overhead larger than the nonce, which is not trivial. Every mandatory request byte we save under MTU is huge.

1 more reply

mbreese13y ago

> and regulatory-compliance standpoint

One of the main reasons why people can't just turn off Cookies is because they are needed for session management. This makes it very difficult to just disable. If there was a dedicated session management method in HTTP/2.0 then that would remove a lot of the need for Cookies. Then they could be used for what they were intended (local persistent state). This would also give users better methods for managing them (or just disabling them).

comexOP13y ago

Eh... maybe eventually, once nothing uses cookies anymore (including existing HTTP sites). But surely this can be solved today by having browsers force cookies to expire with the session?

newman31413y ago

And that is what phk is advocating as part of his proposal. Cookies are the wrong tool to be used for session management.

jfoutz13y ago

you probably know this, but cookies are sent with every damn request the client makes. So it's a tax, It may be a small % of total traffic, but most of the time, it's useless.

comexOP13y ago

It's easy to work around this in a backwards compatible way, though, in a way that's applicable to more than just cookies - in requests after the first, only re-send headers that have changed.

Or just live with the hit while sites migrate to the new mechanism; I'm fine with it being considered a legacy thing.

j / k navigate · click thread line to collapse

0 pointscomex13y ago0 comments

> Why must HTTP 2.x be backwards compatible with 1.x?

> Cookies suck, from a technical

Agreed, but...

> and regulatory-compliance standpoint.

Hah, no you won't. I strongly suspect legacy codebases will remain on HTTP/1.1 approximately forever, at least if 2.0 is backwards incompatible.

0 comments

jasonwatkinspdx13y ago

comexOP13y ago

You can add a concept of session without removing cookies, which are trivial to keep supporting since, as I mentioned, browsers will have to support cookies for legacy sites for a long time anyway.

jasonwatkinspdx13y ago

On top of that, by standardizing on a nonce we avoid all cookie request overhead larger than the nonce, which is not trivial. Every mandatory request byte we save under MTU is huge.

1 more reply

mbreese13y ago

> and regulatory-compliance standpoint

comexOP13y ago

Eh... maybe eventually, once nothing uses cookies anymore (including existing HTTP sites). But surely this can be solved today by having browsers force cookies to expire with the session?

newman31413y ago

And that is what phk is advocating as part of his proposal. Cookies are the wrong tool to be used for session management.

jfoutz13y ago

you probably know this, but cookies are sent with every damn request the client makes. So it's a tax, It may be a small % of total traffic, but most of the time, it's useless.

comexOP13y ago

It's easy to work around this in a backwards compatible way, though, in a way that's applicable to more than just cookies - in requests after the first, only re-send headers that have changed.

Or just live with the hit while sites migrate to the new mechanism; I'm fine with it being considered a legacy thing.

j / k navigate · click thread line to collapse