- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Fri, 20 Jul 2012 13:14:39 +0200
- 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 UTC