Should the IETF ship or skip HTTP 2.0?

Posted Jun 3, 2014 10:07 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Should the IETF ship or skip HTTP 2.0? by nim-nim
Parent article: Should the IETF ship or skip HTTP 2.0?

How a session ID is not a cookie? It'll have all the problems of cookies if you want it to have equivalent functionality.

Should the IETF ship or skip HTTP 2.0?

Posted Jun 3, 2014 18:00 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (8 responses)

A session ID pushes data persistence server side and can be severely scoped by the browser instead of the way cookies make mass tracking dirt cheap (save anything you want in the cookie, allow everything to read it, no data costs, no need to synchronise servers, your target is doing all the work for you.

What changed in the past years is not the ability to spy on people but that's it's so cheap you can even set it up just in case you need it later. Making it a little harder would go a long way to limit opportunistic abuses

Should the IETF ship or skip HTTP 2.0?

Posted Jun 3, 2014 18:04 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Most cookies are used to store session IDs. For example, the Evil Google Cookie only stores a longish session ID.

Next, currently cookies are easily scoped - by their domain. How do you propose to scope session IDs?

Should the IETF ship or skip HTTP 2.0?

Posted Jun 4, 2014 6:59 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (3 responses)

Scoping by fqnd and browser session or fqdn + 1 day/week max.

That would be sufficient to limit abuses.

Should the IETF ship or skip HTTP 2.0?

Posted Jun 4, 2014 20:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Won't help at all. For example, if I place an image from http://google.com/someanalytics on my page and you have a session ID for google.com domain then you'd still be tracked.

And of course, I personally _want_ lots of my sessions to last more than 1 day or week.

And lastly, nobody stops you from deleting cookies every day or restricting them in any way.

Should the IETF ship or skip HTTP 2.0?

Posted Jun 5, 2014 11:54 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> And lastly, nobody stops you from deleting cookies every day or restricting them in any way.

No, because if one gets intercepted, that cookie is good for years.

> For example, if I place an image from http://google.com/someanalytics on my page and you have a session ID for google.com domain then you'd still be tracked.

Use RequestPolicy and don't let J. Random Website force your browser to communicate with any other site. Saves bandwidth too.

Should the IETF ship or skip HTTP 2.0?

Posted Jun 5, 2014 14:25 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> No, because if one gets intercepted, that cookie is good for years.
So? If someone intercepts your session ID they'd still be able to access your data for the duration of the session.

> Use RequestPolicy and don't let J. Random Website force your browser to communicate with any other site. Saves bandwidth too.
You are free to do that with cookies.

Should the IETF ship or skip HTTP 2.0?

Posted Jun 6, 2014 21:15 UTC (Fri) by job (guest, #670) [Link] (2 responses)

Dear god no, don't put "easily" in the same sentence as cookie scoping. Have you actually looked at the ghastly ad-hoc spaghetti that govern that? It involves hard coding pretty much all the TLDs, and that's just the beginning of it.

Should the IETF ship or skip HTTP 2.0?

Posted Jun 6, 2014 21:20 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Whut?

Cookie scoping is easy: http://tools.ietf.org/html/rfc6265#section-4

Should the IETF ship or skip HTTP 2.0?

Posted Jun 6, 2014 22:20 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

Oh, sure, "easy". Until you read sections 5.1.2 regarding canonical host names, and 5.3.5 (which I think "job" was referring to) regarding the ever-varying list of "public prefixes" requiring special consideration--without which any random example.com could register a cookie for "com." and have it scoped over nearly all commercial websites.