
Front-End Performance: The Dark Side - obi1kenobi
https://dev.opera.com/blog/timing-attacks/
======
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.)

------
Dylan16807
Well that's an interesting timing attack in the brows-- _why does Facebook
have a way to create posts that return 404 to specific demographics_?

~~~
paulmd
So your Aunt Susan doesn't see the dank memes you posted. Or those photos of
what you did last weekend.

~~~
Dylan16807
So restrict that to specific lists of people. Don't restrict it to people
claiming to be under 30, or male.

~~~
paulmd
Then you have to diligently add every adult friend to that list forever, and
there will be a gap between when you request their friendship and when you are
friends with them and are allowed to put them on a restricted list.

Blacklists don't work in the Facebook model.

~~~
alexvoda
This would not be a blacklist. What Dylan16807 proposed would still be a
whitelist. It would just use different criteria.

The reason facebook offers those filters is because a lot of posts are public
yet facebook still offers a way to limit the audience.

Filtering the audience using circles is what Google+ did and proved to be
unpopular.

~~~
paulmd
Oh, I think I misread that, but it's slightly ambiguous - are we restricting
_blocking_ to specific people (Aunt Susan is uptight and shouldn't see my
posts) or are we restricting _post visibility_ to specific people? I guess
Dylan probably meant the latter...

I disagree that the failure of Google+ means that nobody wants privacy
settings, or in general that the failure of a business means that every single
minor innovation they made was flawed. Google+ failed because of the network
effect - a social network is only useful if it's also used by people you want
to socialize with.

People consistently list privacy controls as among their biggest problems with
Facebook, and circles solved that problem neatly once people figured out how
they worked. You can of course replicate a circle with a user list on
Facebook, but it's nowhere near as obvious.

------
joe_the_user
This all depends on Facebook knowing one's correct age, then?

I was thinking maybe a hacker could actually judge age by the time that one or
another reflex actions took someone. That would be a whole new level.

------
dclowd9901
I guess I'm missing the practical vector associated with the "compare" timing
attack. All of the js source code is available to see in a debugger, as well
as all of the stored memory values. If you've put sensitive information (a
secret) in the browser, you've already failed...

~~~
mathias
That’s true for client-side JavaScript (like I said in the presentation).

It’s a whole different story if you’re using _server-side_ JavaScript (e.g.
Node.js), though.

~~~
dclowd9901
Absolutely true, but this presentation was about "front end"; maybe I
misunderstand the usage of that term...

