Hacker News Reader

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier."

In fact there's no need for this to be tied in with HTTP/2.0 at all. Alternate systems could be designed without regard to HTTP/1.x or HTTP/2.y, they just have to agree on some headers to use and when to set them.

Making these kind of changes as part of a new version of HTTP would just be bloat on an already bloated spec, it is actually a good thing that the spec writers did not touch this!

> there's no need for this to be tied in with HTTP/2.0 at all.

Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.

This is not equivalent to cookies.

Cookies allow you to specify arbitrary data, not just a session ID, so you can set preferences without having to hit a database or even running a completely static page, using javascript to read the settings.

Cookies as they are now already allow you to control persistence. You can edit or delete them however you wish.

Except that deleting/not allowing cookies will make most of the things we use everyday unusable. Including this website.

Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).

It's really very simple:

Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits.

In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie.

If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session.

If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you.

Of course this can be abused, but not nearly as much as cookies are abused today.

But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.

It also forces the session to be tracked on the server. Many apps use cookies to keep the session in the browser. Maybe deprecating the document.cookie API so that people move to local storage, is a good first step?

More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Seems like anything a server could do via cookies, they could also do via your client-generated session id.

Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id.

If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.

Well, yeah, for a basic implementation, it's rather easy to track like that. What about a system where the unique id returned is based on a random value hashed with the domain name of the window? Then third party trackers would get a different id from you on each site, but your sessions would be static on the site.

True it would make it difficult to do third-party tracking across multiple sites (unless there was server-side information connecting your accounts, like an email address). And leaving aside browser fingerprinting.

That could also just by achieved by disallowing third party cookies though - feels on the cusp of being a browser implementation problem (just stop allowing third party cookies).

This is the link to MinimaLT (it runs on top of UDP instead of TCP). As of today I haven't seen an implementation and MinimaLT being a paper there are some ambiguous parts, but overall this looks like a really well defined spec. It tackles at least the cookie issue. It supports tunneling and it deals with DOS. The other real benefit is that it is RPC based, which means that the protocol is easy to extend (think about NFS and SSH alternatives) and maybe it could be the foundation of a new HTTP. AFAIK it doesn't deal with the CA certs / trust issue.

http://www.ethos-os.org/~solworth/minimalt-20131031.pdf

(Without being pedantic) are you aware of MinimaLT? It is really interesting technology (UDP).

I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.

PHK discusses a lot of these point here: http://www.infoq.com/presentations/HTTP-Performance (especially his views on encryption)

(sorry for the repost, this wasn't posted when I posted the other one)

This is probably a better link: https://www.varnish-cache.org/docs/trunk/phk/http20.html There's a lot of fairly concrete issues in there, concrete suggestions for improvements, concrete suggestions for better problems to focus on (it's hard to overestimate how important that is for proper engineering!), and it's in text instead of a 40 minute video.

I disagree, the link is also interesting, but as I said further down: the video holds an interesting discussion of his views on encryption, especially end-to-end, something the parent explicitly discussed.

So as a problem, he lists server push. What other proposals are there to get rid of stuff like spritesheets?

Just saw it. Basically he's an advocate of the "only bad guys want privacy everywhere".

I still have not seen a single proposal from him that is not "forget about crypto", or "let everything be tracked".

He doesn't seems to even understand how basic key exchange work, and all his arguments boil down to "I think they can break it anyway, so we should stop using it".

IMHO, forget about him. he has no proposal and his understanding of security and crypto is downright dangerous.

You obviously havn't spent much time looking either, have you?

You could look at section 15 here for instance: http://phk.freebsd.dk/words/httpbis.html

With respect to key-exchange, maybe the problem is that I do understand, and therefore know that there is a difference between privacy and secrecy ?

Some places we want privacy, some places we want secrecy.

Mandating privacy everywhere makes it almost mandatory for police-states to trojan the privacy infrastructure (ie: CA's -- yes they already did), and therefore we have neither privacy nor secrecy anymore.

PS: Dangerous for who ?

PPS": Google "Operation Orchestra" if you don't undstand the previous question.

Privacy isn't a binary. Neither is secrecy. It's a function of relationships.

So the question isn't whether children have privacy, but against whom are they able to be private, in what regard? While I'm generally ok with parents knowing where their kids are, I'm not as ok with a random creep in the neighborhood knowing.

As far as criminals and prisoners, it's far more granular than that. If I get caught shoplifting, does that suddenly mean all my medical records are up for grabs? If I am a prisoner, am I allowed to refuse to see someone who comes to visit me?

Police-States would try to trojan the CA infrastructure anyway – its too much tempting a target.

Inspecting proxies work well enough with HTTP 1.1, there's no real need to improve them, and even if we do, it should be done via a proxy mechanism, rather than via sending more things in plaintext than we have.

Anyway, HTTPS routers can (and should) terminate SSL, and in that case they can even read the Host from SNI.

Re the environmental impact: A large contingent of internet networked servers are webservers, transacting with the HTTP protocol (be it spiders or producers or whatever). If it takes more computing resources to provide HTTP/2.0, then it would in fact require more servers, and thus increase the energy consumption.

But given how large datacenter consumers are considering how to build greener/smarter operations to reduce their impact (and costs) then clearly it's something to be mindful of.

> That would have destroyed any hope of adoption by content providers and probably browsers.

Bullshit, browser vendors have always lead the way on web tech. Remember XMLHttpRequest (Microsoft)? How about Javascript or SSL, both invented by Netscape? A proper session layer is inevitable for HTTP. Websites are no longer stateless, making HTTP an ill-suited protocol. We should just accept it and move on.

I believe that browser vendors will push technology that benefits them. That's definitely not in dispute. But you need to convince them that HTTP/2.0 is beneficial to them, and I don't think that will be easy if content providers aren't serving content via HTTP/2.0.

Most of the enhancements I'm aware of HTTP/2 are centered around SPDY.. along with persistent connections. The upconvert for SPDY and WebSocket connections are interesting on HTTP/1.0, I kind of wish that this had worked hand in hand with DNS to allow for DNSSEC publishing of public encryption keys for use with HTTP, then HTTP negotiating against that key.

I also wish there were layer between full encryption for content that is intended to be available for http and https (without the extra overhead) for signed content.

What you want re public keys in dnssec secured DNS is called Dane. Browsers are slow to implement it though.

if you need to have a stateful connection, why not just use websockets? in many other cases (eg asset fetching) http/http2 are fine

> That would have destroyed any hope of adoption by content providers and probably browsers.

why adoption by browsers?

I'm less sure browsers wouldn't adopt, but if content providers are slow to adopt due to massive changes in how they handle sessions / tracking / everything else they do with cookies, browsers are not incentivized to adopt.

I suspect it would end up looking similar to IPv6: Unless ISPs are providing the majority of users with IPv6, software developers aren't well incentivized to support IPv6 in their software. Similarly to browsers, they'd lose very little for supporting the new standard now, but the gains are low while adoption by the other group is low.

I don't see how this should stop us from fixing legitimate problems. As far as I know IPv6 adaptation is not a software problem at this point.

You are not fixing legitimate problems if the new spec never gets adopted by anyone.

That's not really my position to represent though. As an engineer you have to be firm if the issue is worthwhile. Just because the tech industry is a largely a vertical oligopoly doesn't mean we should support it. Technology would be a better place if the parties opposing security, robustness, privacy etc. would have to take an active stand against it rather than being able to hide behind vague design decisions. I do also think there are things that aren't worthwhile to be fighting for though.

The new spec wouldn't get adopted it if didn't offer anything better. See: IPv6

"won't". It hasn't been adopted by even a significant portion of the internet yet, and based on these discussions I'm fearful it will turn out exactly like IPv6.