On Tue, Jul 9, 2013 at 3:54 PM, Joseph Bonneau <[email protected]> wrote:
>> Yes. Unfortunately, I don't see a way to have both HPKP and automatic >> defense against this kind of super-cookie. The problem exists for >> HSTS, too. > > I agree, but there are two things user agents SHOULD do at a minimum: (a) > clear pins for domains whenever other domain-specific information is cleared > for privacy reasons (delete history since time N, or private browsing mode) We currently have decided NOT to do this for HSTS. You can see the somewhat tortured history of the behavior in Chrome here: https://code.google.com/p/chromium/issues/detail?id=104935 Chrome's Incognito mode is an easy way to get Chrome to not persistently store any local state (thus defeating a wide range of super-cookie techniques, including but not limited to ETag, HSTS, HPKP, cache hit/miss timing). If you are concerned about privacy side-effects from local state, use Incognito. (Also, it behooves me to refer to the official Incognito documentation: https://support.google.com/chrome/answer/95464?hl=en) > (b) not store pins in cases where cookies will not be rejected for privacy > reasons (such as third-party cookie blocking policies). I don't think these > are obvious to implementers so I would like to seem them in the spec. I'm not sure what you mean here. Did you mean to write, "not store pins in cases where cookies WILL be rejected for privacy reasons"? Note that the HSTS and HPKP super-cookie is primarily useful for *recovering* a previously-set but then deleted cookie — it does not by itself allow the server to *easily* correlate requests, only to laboriously recover a thing (like a cookie) that does. So if the UA is blocking (say) third-party cookies anyway, the HSTS/HPKP super-cookie technique might not work too well for the third-party adversary. Or at least not as well as other techniques that are already available. I believe we are in the privacy margins here. Incognito mitigates the concern; blocking third-party cookies somewhat mitigates the concern; N-host HSTS/HPKP super-cookies are (probably? I think?) not the most efficient of the many available super-cookie techniques; I assume everyone likes the report-uri feature and that we don't want to get rid of it; et c. As far as I know, the ETag/Last-Modified super-cookie technique is unsolved (http://www.nikcub.com/posts/persistant-and-unblockable-cookies-using-http-headers), and much more straightforward for implicit-tracking adversaries to use. _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
