41–50 of 138 posts
Earlier quoted context omitted.
If I'm interpreting that correctly, that could be a huge win for privacy
How so? A unique identifier is a unique identifier.
I think that would actually work very nicely.
Earlier quoted context omitted.
Why must HTTP 2.x be backwards compatible with 1.x? Should SSH have not been created because you can't talk to it with a telnet client? If a new protocol offers sufficient benefits, it would be worth having to make minor changes to apps to support both. Cookies suck, from a technical and regulatory-compliance standpoint. Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal…
HTTP/2.0 doesn't have to be backwards compatible at all. In fact, I see the future protocol switch being pretty simple. There will be new HTTP/2.0 servers and HTTP/1.1 legacy servers. The clients will speak either language, but 2.0 servers will be faster. Eventually clients will let the user say if they want to talk to 1.1 servers at all. The initial line will remain the same, except for the version: GET /page HTTP/2…
The very least, you want the server-provided identity header to be before all the variable-length fields, because in normal situations, most high-throughput servers will be able to fully route their traffic on it alone.
Earlier quoted context omitted.
How so? A unique identifier is a unique identifier.
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.
(These are just my opinions as web developer. Please feel free to downvote if my expectations are wrong) While I can completely agree with the technical merits of this proposal, there are some very two-faced statements. Author begins by pointing out the painfulness of IPv4 to IPv6, says that the next HTTP upgrade should be humble . But then proceeds to kill cookies and remove all the architectural problems in HTTP. I…
One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business.
If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business would have killed to get it back in the late 1990ies.
Cookies only disappear from the wire, they are trivial to simulate on your server (see my other reply here).
(These are just my opinions as web developer. Please feel free to downvote if my expectations are wrong) While I can completely agree with the technical merits of this proposal, there are some very two-faced statements. Author begins by pointing out the painfulness of IPv4 to IPv6, says that the next HTTP upgrade should be humble . But then proceeds to kill cookies and remove all the architectural problems in HTTP. I…
That's not good enough. The big problem is that you need the headers to properly route the request to the correct server. So for most operations, there will have to be one machine that is capable of reading all the headers of all the requests that arrive. gzipping the headers makes the job of this machine much, much harder.
While in general I understand where he is coming from, I believe his main argument about adoption is flawed. What do you think is more likely going to be adopted? A protocol that's not backwards compatible at all (heck, it even throws out cookies) or something that works over the existing protocol, negotiating extended support and then switching to that while continuing to work the exact same way for both old clients…
Google being able to modify both the client (Chrome) as well as few fairly significant server installations has kind of helped there a little bit...
Removing cookies from a protocol which is otherwise fully compatible with HTTP/1, in the sense of being able to be interposed as a proxy or substituted in the web server without breaking apps, is a terrible idea. > Cookies are, as the EU commision correctly noted, fundamentally flawed, because they store potentially sensitive information on whatever computer the user happens to use, and as a result of various abuses…
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…
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 recognized by the server without constant re-authorization.
> Today users don't have that choice, since they have no realistic way of knowing which cookies belongs to a particular website due to 3rd-party cookies and image-domain splitting etc.
I don't see how this makes sense - what's the difference?
Assuming that the session identifier is different between sites (if it's not, then the user has no option to "remove cookies" for a single domain without deauthenticating everywhere, and it's harder to determine which sites are tracking you):
- There will still be third party domains involved, since advertisers will still want to correlate traffic between domains;
- Sending a new session identifier with every request won't be practical, because you won't be able to log in, but users will be able to set their browsers to send a new identifier when the window is closed or whatever... just as they could currently configure their browser to clear cookies at that time.
Also, anyone who wants to abuse cookies can just use localStorage.
> But the only reason HTTP requests don't fit in a single packet to begin with is cookies, get rid of cookies, and almost all requests fit inside the first MTU.
Surely it's still useful to deflate things (user-agent...), though, and then what does it matter?
> Finally, eliminating cookies improve caching opportunities, which will help both client and server side get a better web experience.
How so? The server is perfectly justified in sending different content based on the session identifier, so wouldn't a proxy have to assume it would?
But if you want to say the result doesn't depend on cookies, can't you just set a Vary header?
> It is trivial to write a module for apache which simulates cookies for old HTTP/1 web-apps: Simply store/look up the cookies in a local database table, indexed by the session-id the client provided.
Eh... okay. This still breaks anything that uses JavaScript to interact with the cookies.
(These are just my opinions as web developer. Please feel free to downvote if my expectations are wrong) While I can completely agree with the technical merits of this proposal, there are some very two-faced statements. Author begins by pointing out the painfulness of IPv4 to IPv6, says that the next HTTP upgrade should be humble . But then proceeds to kill cookies and remove all the architectural problems in HTTP. I…
No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs). One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business. If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business wo…
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.…
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.
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 of the sites that are vulnerable are the kind of old-fashioned things that will never be upgraded anyway.