[willscott]

This is a cool side-channel attack that makes use of two nuances in the web.

First, the cache storage mechanism in service workers allows a site's javascript to cache a 3rd party request it has loaded through the fetch API. Caches aren't thinking about timing attacks, and in general are performance sensitive, so it's reasonable to expect that larger resources will take longer to cache and this time can be observed by the page.

Second, you can generate facebook posts which are targeted to specific demographics - like age ranges or specific ages. This will generate URLs which will have a different page length when loaded by logged in users in the target demographic compared to others. It looks like this is possible because there is not an explicit 'access-control-allow-origin' header set on facebook, and while the 'x-frame-options:deny' prevents loading of the content, it can still be cached by a 3rd party.

[tomvangoethem]

The attack on Facebook (or any other website for that matter) works regardless of any Access-Control-Allow-Origin headers. The Fetch API has a mode "no-cors", which does not require CORS. Also: the cache being used is a programmable cache, which is distinct from the regular cache in the sense that any website can place any resource in it, regardless of the headers sent along with the response.

(I'm one of the researchers mentioned in the presentation.)

[mathias]

> It looks like this is possible because there is not an explicit 'access-control-allow-origin' header set on facebook

CORS has nothing to do with it, actually. This is where the strength of the attack lies.