Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Varnish author criticizing HTTP/2.0 proposals

lists.w3.org

Post reply on HN
Print view View original

51–60 of 138 posts

Re: Varnish author criticizing HTTP/2.0 proposals

#51

Post by phkamp »

comex wrote: post #47
phkamp wrote: post #35

Earlier quoted context omitted.

I agree that anybody with sufficient clue can and will use cookies as id only. Unfortunately such people are evidently few and far between. Banning cookies and having the client offer a session identifier instead solves many problems. For starters, it stores the data where it belongs: On the server, putting the cost of storage and protection where it belongs too. This is a win for privacy, as you will know if you hav…

> This is a win for privacy, as you will know if you have ever taken the time to actually examine the cookies on your own machine. Most of the cookies I've seen are some kind of hash. > Second, it allows the client+user to decide if it will issue anonymous (ie: ever-changing) session identifiers, as a public PC in a library should do, or issue a stable user-specific session-id, to get the convenience of being recogni…

The client/user-agent gets to control what session-id gets sent to which sites.

That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites.

That will make tracking and correlation of webusage much harder, which I really don't see a downside to.

Deflate is bad on its own, it is a DoS amplifier and it makes the job of load-balancers much more resource intensive, because they have to retain compression state for all connections and spend CPU and memory on the inflation.

The server is perfectly justified in customizing content, and we have a header for saying that is the case: Cache-Control.

The problem with cookies is that they disable caching of everything on the site, including favicon.ico and there is nothing the server can do about it, because the cookies are sent on all requests.

Javascript will also have access to the session-id.

Re: Varnish author criticizing HTTP/2.0 proposals

#52

Post by newman314 »

mbreese wrote: post #23
comex wrote: post #8

Earlier quoted context omitted.

> Why must HTTP 2.x be backwards compatible with 1.x? Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk... > Cookies suck, from a technical Agreed, but.…

> and regulatory-compliance standpoint One of the main reasons why people can't just turn off Cookies is because they are needed for session management. This makes it very difficult to just disable. If there was a dedicated session management method in HTTP/2.0 then that would remove a lot of the need for Cookies. Then they could be used for what they were intended (local persistent state). This would also give users…

And that is what phk is advocating as part of his proposal. Cookies are the wrong tool to be used for session management.

Re: Varnish author criticizing HTTP/2.0 proposals

#53

Post by angelbob »

danellis wrote: post #43
angelbob wrote: post #28

Earlier quoted context omitted.

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.

Re: Varnish author criticizing HTTP/2.0 proposals

#54

Post by jasonwatkinspdx »

comex wrote: post #49
jasonwatkinspdx wrote: post #31

Earlier quoted context omitted.

If you would bother to read the full thread as well as PHK's position proposal you'd see that removing cookies brings more than a tiny benefit. The overall flavor of his proposal is to reify a concept of session and by that eliminate redundant communication. At the same time we get substantial wins in security.

You can add a concept of session without removing cookies, which are trivial to keep supporting since, as I mentioned, browsers will have to support cookies for legacy sites for a long time anyway. I doubt the security argument amounts to much, considering that there are few sites with cookie-based vulnerabilities, it's long been trivially easy ($_SESSION in PHP) for any site to use identifiers as cookies, and many o…

Once you have a concept of a session unique nonce, cookies are needless. Browsers can implement a locally encrypted resumption store where the user entered entropy never touches the network to resume a session on the same machine. Resuming a session on a new machine could use 2 factor auth with fallback one time capabilities. That's big, doubly so given the clear historical trends in users ability to memorize entropy and the likelihood of hashed password database disclosure.

What you need to understand, is that we can get rid of cookies, live in a more secure world, and give up nothing. The only thing holding us back is unwillingness to understand the underlying issues and fear that we stand to lose something by advocating change.

On top of that, by standardizing on a nonce we avoid all cookie request overhead larger than the nonce, which is not trivial. Every mandatory request byte we save under MTU is huge.

Re: Varnish author criticizing HTTP/2.0 proposals

#55

Post by comex »

phkamp wrote: post #51
comex wrote: post #47

Earlier quoted context omitted.

> This is a win for privacy, as you will know if you have ever taken the time to actually examine the cookies on your own machine. Most of the cookies I've seen are some kind of hash. > Second, it allows the client+user to decide if it will issue anonymous (ie: ever-changing) session identifiers, as a public PC in a library should do, or issue a stable user-specific session-id, to get the convenience of being recogni…

The client/user-agent gets to control what session-id gets sent to which sites. That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites. That will make tracking and correlation of webusage much harder, which I really don't see a downside to. Deflate is bad on its own, it is a DoS amplifier an…

> That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites.

This is already possible, just give tabs their own cookie context by default. (Browsers don't make this the default, but they all have some variant of "incognito mode" already...)

> The problem with cookies is that they disable caching of everything on the site, including favicon.ico and there is nothing the server can do about it, because the cookies are sent on all requests.

I admit that I don't know much about HTTP caching, but I don't see why the Cookie header would inhibit caching. (Edit: Isn't the purpose of the Vary header to specify which request headers affected the result, including Cookie?)

Re: Varnish author criticizing HTTP/2.0 proposals

#56

Post by regularfry »

How protocol adoption happens, in three steps:

1. Working code. 2. Publicity. 3. Ubiquity.

That's it. Kamp is making a lot of the right noises here, but he's already lost ground to SPDY just because they've shipped code. No amount of sitting round tables bashing out the finer details of a better spec will help as much as getting code written - even if it's just a placeholder for an extensible spec, as long as that placeholder does something useful.

Re: Varnish author criticizing HTTP/2.0 proposals

#57

Post by phkamp »

phkamp wrote: post #51
comex wrote: post #47

Earlier quoted context omitted.

> This is a win for privacy, as you will know if you have ever taken the time to actually examine the cookies on your own machine. Most of the cookies I've seen are some kind of hash. > Second, it allows the client+user to decide if it will issue anonymous (ie: ever-changing) session identifiers, as a public PC in a library should do, or issue a stable user-specific session-id, to get the convenience of being recogni…

The client/user-agent gets to control what session-id gets sent to which sites. That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites. That will make tracking and correlation of webusage much harder, which I really don't see a downside to. Deflate is bad on its own, it is a DoS amplifier an…

(probably pressing wrong reply link here ?)

Cookies are almost never mentioned in Vary: so all caches have to assume that the precense of cookies means non-cacheable.

Re: Varnish author criticizing HTTP/2.0 proposals

#58

Post by mike-cardwell »

I can think of a few organisations that benefit financially, a great amount from the fact that cookies allow them to track users. Ad companies like Google and Microsoft spring to mind. The same organisations building our major browsers... Conflict of interest? You better believe it.

Re: Varnish author criticizing HTTP/2.0 proposals

#59

Post by comex »

jasonwatkinspdx wrote: post #54
comex wrote: post #49

Earlier quoted context omitted.

You can add a concept of session without removing cookies, which are trivial to keep supporting since, as I mentioned, browsers will have to support cookies for legacy sites for a long time anyway. I doubt the security argument amounts to much, considering that there are few sites with cookie-based vulnerabilities, it's long been trivially easy ($_SESSION in PHP) for any site to use identifiers as cookies, and many o…

Once you have a concept of a session unique nonce, cookies are needless. Browsers can implement a locally encrypted resumption store where the user entered entropy never touches the network to resume a session on the same machine. Resuming a session on a new machine could use 2 factor auth with fallback one time capabilities. That's big, doubly so given the clear historical trends in users ability to memorize entropy…

There is no difference between browsers implementing a locally encrypted resumption store for a nonce and for cookies (since again, most sites where security is important already use cookies purely as identifiers); nor does it affect whether sites will start requiring two factor for all logins. The two systems are equivalent except that one is simpler, but the (small amount of) complexity of cookies is not what's blocking these types of security measures.

I'm not saying additional login security isn't a good idea (although since local cookies tend to be compromised by malware running on the machine rather than offline attacks, it may not be that useful to encrypt them), and I'm not saying that avoiding cookies isn't a good idea, because cookies do tend to get bloated. But tying the two proposals together is unhelpful to both, because they're essentially orthogonal.

As for avoiding cookie request overhead, that is again something you can do by adding a standard nonce without actually removing the old mechanism; sites that want to be fast or have a standardized way to interact with HTTP routers, and most sites that use web frameworks, as the frameworks get updated, will use the new one. The only way removing cookies would help is if servers started translating cookies for legacy applications automatically, but I don't see that becoming prevalent because of document.cookie and related concerns.

edit: and again, breaking backwards compatibility is a great way to slow HTTP/2 adoption, not that it really matters unless it brings TLS to all sites along with it (but that's another story...)

Re: Varnish author criticizing HTTP/2.0 proposals

#60

Post by squidi »

ajankovic wrote: post #32

In my opinion it is always a good idea in these kind of situations to set a goal we should strive to. I wonder what the ideal web protocol would look like. If, for example, we didn't have a burden of billions of servers and Internet reliance on HTTP/1.x protocol. What would be the most ideal solution that would suite emerging use cases for the Web? Are there any research papers on this topic?

I agree with this way of thinking. phkamp has come up with some innovative ideas, but if it doesn't come easy for the rest of us there are lots of techniques to help e.g. asking, "if I was superman and could implement any solution, what would it be" http://personalexcellence.co/blog/25-brainstorming-technique...
Post reply on HN