Varnish author criticizing HTTP/2.0 proposals

That's the opposite of the general consensus in the webdev-community.

Client-state is not only vastly more efficient in many cases but it also usually leads to cleaner designs and easier scaling.

Many of the modern desktop-like webapps would be outright infeasible without client-state. What's your response to that, should we just refrain from making such apps in the browser?

If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser

And at the same time you probably appreciate when on your slow mobile-link the "add-basket" operation happens asynchronously, yet doesn't get lost when you refresh the page at the wrong moment.

I'm a bit confused here. You know better than most how critical latency is to the user-experience. Saving on server-roundtrips or hiding them is a big deal.

Yet you promote this dogma without providing an alternative solution to this dilemma.

The difference is that the decentralized approach would put more control in the hands of the user (so they either take care themselves or hire someone to take care for them). If they want to.

"Address is not a private bit of info" - it's person and context dependent. Some people consider their name a private bit of info in some contexts... And yes you have to send the shipping info to the remote party to ship you stuff. But they do not have to keep it neatly packed one select away.

I still have a difficulty understanding how the "random session-id" will solve the problem of privacy. All I can see happening is one more level of indirection, that will cause the creation of the frameworks to re-collate this back. Because this is a functionality that is needed by the developers. And once you have the commonly available code, you're back to previous stage - except with an additional pile of code to debug.

I'm not saying all of this because I think we should stop trying. It's just that I can't see how the cost of uplifting the entire internet infra (the code required for this functionality will surely be much more storage than the cookies over my lifetime) and the cost of having the programmers support both models for the good chunk of future (hello, IE6 users, I am looking at you! :-) justifies the incremental feeling of security that this gives.

edit: re. sending the data to the trusted server: sign with your client key a "request for data" together with the manifest of the addresses that the server can plausibly have. Then when the server needs the data it can present this request to your UA and get the data. Yes, the server can be hacked and this data can be siphoned off. But then the attackers get the [timespan of the breach] worth of user data, and not the entire DB.

No I don't see the difference at all. So you got lucky, and didn't have you computer targetted early on by a 0-day virus. Congrats, I'm sure your luck will keep up forever.

I'm not saying all of this because I think we should stop trying. It's just that I can't see how the cost of uplifting the entire internet infra (the code required for this functionality will surely be much more storage than the cookies over my lifetime) and the cost of having the programmers support both models for the good chunk of future (hello, IE6 users, I am looking at you! :-) justifies the incremental feeling of security that this gives.

Now you are conflating the sole benefit of session ids with the security benefit. There are other benefits. Read the article, there are benefits to "http routers" that would come from it. Look at my comment history, I mention a couple (cache locality benefits from routing, ability to standardize login stuff and use http auth reasonably again, without reinventing the wheel every site/framework). Others have mentioned other benefits. The incremental security benefit is but one of these.

I'm not saying all of this because I think we should stop trying. It's just that I can't see how the cost of uplifting the entire internet infra (the code required for this functionality will surely be much more storage than the cookies over my lifetime) and the cost of having the programmers support both models for the good chunk of future (hello, IE6 users, I am looking at you! :-) justifies the incremental feeling of security that this gives.

This is a strawman, yes there are still places on legacy systems, but more and more are adopting systems that allow standards based approaches and faster upgrade cycles (ala adopting chrome or firefox), there is no reason to doubt this trend will continue.

edit: re. sending the data to the trusted server: sign with your client key a "request for data" together with the manifest of the addresses that the server can plausibly have. Then when the server needs the data it can present this request to your UA and get the data. Yes, the server can be hacked and this data can be siphoned off. But then the attackers get the [timespan of the breach] worth of user data, and not the entire DB.

This looks to be a usability nightmare. Further, at best it is no better of a solution than the one i presented - an incremental change that requires lots of code. As soon as this starts happening in a widespread way, the attack patterns will change from server hacking to browser hacking in a serious way. Or finding ways to hack the http gateways where ssl is dropped, and which are frequently appliances harder to monitor for security. Or there will be more phishing attacks using sophisticated key stealing techniques to get real credentials. Or DNS attacks. Or as plug devices get super cheap, piles of mitm attacks on places with wifi, or or or... security is always incremental.

For the webapp-developer, which results in a faster and cheaper experience for the user.

I'm still baffled at your persistence given you sit pretty much at the source. You have probably written VCLs for sticky sessions yourself and pondered the constraints wrt data-locality and single points of failure? Sticky sessions are just not a good design when the alternative is so readily available; it's the first time in a long time I hear anyone disagree with that.

That kind of cookie usage just makes it Somebody Else's Problem instead of your problem.

And who would that "somebody else" be?

Users certainly don't care about a few hundred extra-bytes that their browser sends with each request, especially since that trade-off usually makes their browsing faster than the alternative would be.

The privacy concern is valid but boils down to developers using cookies wrong (without encryption). If we were to remove all technologies that are used wrong by incompetent developers then the internet would be a pretty empty place.