RE: Browser Fingerprinting using HSTS and CSP

But what if it also works for the redirect cache? It could be done for any request then.

 

From: Mike West [mailto:mkwst@google.com] 
Sent: 03 December 2015 09:54
To: Mike O'Neill <michael.oneill@baycloud.com>; yan zhu <yan@mit.edu>
Cc: Nick Doty <npdoty@w3.org>; Keiji Takeda <tkeiji@w3.org>; public-privacy (W3C mailing list) <public-privacy@w3.org>
Subject: Re: Browser Fingerprinting using HSTS and CSP

 

On Thu, Dec 3, 2015 at 10:45 AM, Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> > wrote:

I think the attack is about measuring the time delay between a CSP blocked
XHR request and the resulting oneeror, then detecting whether a site had
been visited by measuring a short delay (because the url would be cached).
We could recommend that the UA inserts a random ~100ms-ish delay before
triggering events from CSP blocked requests. It only needs to be there for
cross-origin ones.

The only difference I know about for CSP support in Firefox is that they do
not currently support CSPs in meta tags, but I believe that is about to be
released anyway.

 

Yup. Yan is awesome.

 

We've addressed the attack she exposed in the CSP spec by disallowing folks from locking themselves into insecurity. That is, `img-src http:` now means `img-src http: https:`. Firefox accidentally implemented this behavior while working on Upgrade Insecure Requests, and it turns out to have been a wonderful accident that we've implemented in Chrome as well (in beta now, I think).

 

AFAIK, Yan has a more general version of the attack that doesn't rely on CSP. CSP just made it ~100% effective. (+yan)

 

-mike