If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.

Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way.

But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP.

Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause.

And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol.

Nobody seems to have heard the expression "Festina Lente" in this WG.

It absolutely does, global passive attackers have been documented using the associated unencrypted tracking cookies to find targets.

On the protocol level, there is a huge knowledge and API momentum that makes any protocol that fundamentally differs from HTTP an uphill battle for adoption. Whatever changes are made to HTTP, if it is too different from the application POV, it will linger behind.

Same thing about tunneling. It may not be elegant, but it's the way to fight the system. You won't change IT behaviour with a protocol change. One possible way to work would be to make new version oF HTTP have a working mode that reduces overhead to a minimum for any tunneling operation.

(The same argument hold to SCTP vs TCP.)

There's nothing "practical" about HTTP/2.0. I've read the spec, since I was interested in it, and it confused the hell out of me. Then I learned that even people who implement networking specs for a living, and have tons of experience at it, are stuck trying to figure out how to implement the current spec.

So if you're going to push for shitty-but-practical, at least make sure you have the practical bit.

For instance moving cookies to the server side would just require a simple key-value store lookup.

Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead?

Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?

My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session.

A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time.

This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.

Or are you pushing for browsers to turn off cookies by default?

But an active man-in-the-middle attack at least has a chance of being detected, as opposed to the current passive sniffing being done on a wholesale basis. Do you not see any value in that?

(I have not followed the HTTP/2 development closely enough to comment on other areas of concern.)

I'm opposed to a protocol which claims to "improve privacy" while leaving some of the most troubling privacy invasions in place.

If we are going to the trouble to upgrade HTTP, we fix all the serious problems we can.

Yes, they add request and response overhead but what evidence is there that removing them would deliver greater performance improvements than a multiplexed protocol does?

The answer is that well-designed cookies are incompressible because they come out of cryptographic algorithms.

Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them.

Using information-free session nonces would have neither of these problems, and take up much less bandwidth.

If it didn't have HPACK but still did multiplexing would you still say abandon it?

Can you spell this out in more detail? (Maybe you've written an article about this at some point?)

When, if ever, is it OK to store state on the client? It seems like you'd at least make an exception for one session ID. I presume you'd also make exceptions for client-side caches? Anything else?

Do you advocate against all forms of client-side storage? IndexedDB, localStorage, Web SQL, etc?

RESTful advocates keep telling me not to store state on the server. Do you agree with that? If I can't store state on the server and I can't store it on the client, where am I supposed to store it?