Front-End Performance: The Dark Side | Hacker News Reader

Front-End Performance: The Dark Side

dev.opera.com

110 pointsobi1kenobi13 comments

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.

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.)

> 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.

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?

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

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

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.

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.

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.

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.

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...

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.

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

Reply on news.ycombinator.com