Hacker News Reader

Comment by sciurus | Hacker News Reader

His proposal is at http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-archit...

It comes with the caveats that "Please disregard any strangeness in the boilerplate, I may not thrown all the right spells at xml2rfc, and also note that I have subsequently changed my mind on certain subjects, most notably Cookies which should simply be exterminated from HTTP/2.0, and replaced with a stable session/identity concept which does not make it possible or necessary for servers to store data on the clients."

View on HN

If I'm interpreting that correctly, that could be a huge win for privacy

How so? A unique identifier is a unique identifier.

If the browser created the unique identifier instead of the server it could create a new one as often as necessary.

I think that would actually work very nicely.

Browsers can do that now with cookies, by just clearing old cookies.

If you don't store a leakable cookie on the client and only use a connection ID (which is autoassigned by the server and cannot be easily forged) then a lot of cross-domain evil hackery goes away.

I don't know what you mean by 'leakable' exactly, but you can already mark cookies as HttpOnly (not accessible from Javascript) and Secure (only transmitted over HTTPS).

"Leakable" in the sense that you can hand it to somebody else and they can actually use it.

A cookie is leakable because the client chooses to send it, so copying it to somebody else is really bad. A server-assigned per-connection ID is not leakable unless you can spoof the IP address of the one you're sending as.

In principle you could already achieve that by binding a session (and corresponding cookie) to the client's IP address. No big deal.

Problem you may have is that some clients are behind proxy farms and can arrive with different source IP addresses within the scope of a single session.

If you do not bind the 'server-assigned-per-connection ID' to an IP address they become just as 'leakable' as a session cookie.

Doing server side IP checks is already easy, but in reality it can lead to massive amounts of user complaints when their sessions keep disappearing, because as it turns out, some user segments have a lot of users coming through proxies where each request is not guaranteed to come from the same IP.

Or their mobile device roams from WiFi to cell data.

I suspect anyone suggesting that an IP be part of the session security has never actually tried it on a large scale.

Sure. It'd be nice to have some kind of actual standard to at least make a good best guess here. Cookies are a really, really bad start.

Then a translation device at carrier assigns the client a different address. I heard first-hand that this is very annoying.

Of course, but the question is what that unique identifier denotes.

An IP address tells people who you are, where you are, and what you do.

A unique identifier ('+18El1iZRFCIiqRpfw4dJR8mXjJn2UxPrjwoRNpjSWg=' for instance) tells what you do without the who and where [1].

It's even possible advertisers could still target users based upon these identifiers, just without the background knowledge that makes these sorts of things privacy issues.

[1] I'll admit, it could be argued that the what can determine the who and where

Maybe he's trying to bring light to Unhosted?

Reply on news.ycombinator.com