W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Introducing a Session header...

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Fri, 20 Jul 2012 13:14:39 +0200
Message-ID: <8d6b6668433e8aa7c67601ab9b0f485d.squirrel@arekh.dyndns.org>
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Amos Jeffries" <squid3@treenet.co.nz>, "Willy Tarreau" <w@1wt.eu>, ietf-http-wg@w3.org

Le Ven 20 juillet 2012 12:41, Poul-Henning Kamp a écrit :
> In message <9c4a1f3bd08bf10c608b2c01f01440b2.squirrel@arekh.dyndns.org>,
> "Nicol
> as Mailhot" writes:
>
>>1. at the start of a stateful interaction the server (only actor that
>>knows it will need state) challenges the user agent for a new unique id,
>>and provides a unique state tag (short so it can not be abused for
>>anything else)
>
> I think we can speed up this safely by allowing the client to always
> offer a unique ID without being asked.  If the server doesn't need it,
> it will just ignore it.

The problem if you do it this way is that:
1. state becomes implicit to anyone but the server
2. the user agent has no information when it can switch id without
breaking apps
3. the user agent has no information if it should share the id with
another site or not
4. you make it unsafe to cache anything if app writers posit (as they will
if you don't force them to delimit state boundaries) that they can rely on
responses not being shared between user agents that sent different ids

So user agents will end up publishing all the time an id with indefinite
lifetime, on all web sites (I'm pretty sure this is bad for privacy, it
would be worse than the doubleclick cookies)

Now of course I'm not a security expert so I'll bow to their judgement.

-- 
Nicolas Mailhot
Received on Friday, 20 July 2012 11:15:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 11:15:34 GMT