Hacker News Reader

Comment by lidHanteyk | Hacker News Reader

I still liked PHK's suggestion for removing cookies entirely from HTTP/2 [0]. I seem to remember that they advocated for instead having the user agent send a profile ID which is only meaningful to the user agent. That would allow the server to know which requests belong to which profiled user, but allow the user full control over which profile is presented.

[0] https://varnish-cache.org/docs/trunk/phk/http20.html#beating...

View on HN

Everyone would've emulated cookies using HTML local storage, because it would be a pretty quick fix (just wrap all cookie API's). So you'd gain nothing except push people from a standard to an ad hoc solution.

Switching to server side storage would've been a too costly architectural change. What if the server side was stateless before?

And even if, web applications would still have needed to support the old model for interop reasons. It's not feasible for everyone to maintain code for both approaches when they are so different.

It'd also break many use cases, such as using a (signed) cookie as cache for some really frequently used data. Or more importantly authentication, where an auth service returns a token (in some cases a token that can be checked by a different service without contacting the auth service again).

So yeah, that was a non starter.

> What if the server side was stateless before?

Then that's a pretty bad design choice to begin with? If some state is required for operation, but the website keeps it only on client? Not least of all reasons, for security?

You can make such state cookies tamperproof with server side signing. Depending on the state in question, leaving it with the client, instead of in server storage, makes for good lifetime management. Of course, if you want the state to be synced between different clients (for a logged in user or something), you'll need to do something else.

Statelessness is often a good thing in designs in many ways, performance, reliability, maintainability, operating cost etc.

As a concrete example for a common use case, websites show your user or first name in the top right corner. It's common to put this in a cookie set on login/logout. This avoids querying the user directory service (from the frontend or a different backend service) on every pageload. Security wise it doesn't matter if the user tampers with it, it's a display only thing. (More often than not it's signed anyway, and the cookie contains other things as well.)

Cookies meant to be presented back to a server can be signed and (optionally) encrypted. This is also a very widely used pattern ("cookie secret" is a good search term for concrete implementations in frameworks).

You can't have your cookie and eat it, too; the browser has to store profile information or cookie information either way, so this was never about statelessness. This is about the expectation that user agents will not just consent to server tracking, but carry around papers which will identify themselves to each server so that they can be better tracked.

I'm sorry if I didn't explain what I meant well enough.

I was talking about statelessness on the server side. If you remove cookies from HTTP, you now need a database on the server side.

You also get extra communication (between the client/DB, or the web service/DB), whereas previously the data would've already been available in both (the client has the jar, and the web service gets it in each the request). Turning a local memory read into a network request can be a difficult architectural change.

Also, DynamoDB reads are priced per unit ;-)

That would mandate server-side storage for sessions and any kind of persistence though. It feels like that's throwing away the baby with the badwater.

Reply on news.ycombinator.com