
Protecting user identity against Silhouette - stablemap
https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitter_silhouette.html
======
rsj_hn
For those who might have a hard time going through the summary, the attack is
very simple:

If I block you, then when you load my twitter page, the load takes less time
than if I don't block you.

So if the attacker wants to track 2^^N users, they number these users 1 ...
2^^N and each user can be given a binary number that is 0 or 1 in N positions,
corresponding to whether N fixed accounts block them or not.

So, there is a lot of set up work to create N bot accounts that together block
or don't block 2^^N people.

Then, the attacker tricks a user to loading their webpage which has a script
that loads each of the N twitter profiles. If you are logged into twitter,
your session cookie will be sent and the load time will be different or not
for each of these accounts and so the attacker will be able to identify you if
you are in the group of 2^^N users.

This type of attack is awesome (in a dark way) in that it can work for a lot
of sites other than twitter. It points out a general weakness whenever a
social media website takes a different time to load based on an attribute not
in your control.

For example, it doesn't work with 'friends' if you need to approve friends, as
you wont approve the bots friending you, but you can't block the bots from
blocking you. Amazing.

The long term solution is same site cookies, which is also a solution for a
lot of these CSRF type attacks. Great stuff.

------
eridius
This explains why visiting twitter.com has been horribly broken for months.
Literally every time I try to visit twitter.com in Safari, it would just load
a blank page and do nothing, and I'd have to manually reload before it would
come back to life.

Though trying right now it's working. So either they changed something, or
upgrading to Safari 12 fixed this issue (or turning off legacy extensions did,
which was a side-effect of upgrading to Safari 12, though I wouldn't expect
Ghostery or the DuckDuckGo extension to prevent twitter.com from reloading).

~~~
justacomme555
The article describes that certain privacy extensions break the page from
loading. It was probably ghostery.

Honestly though the blank page fix seems horrible... especially when you
consider twitter has worked very hard for the “above the fold” load times, at
one point rendering it server side.

I also wonder if the attacker just pops a new window ( after getting the user
to click anywhere) and load the twitter page into it, if they can still time
the request the same way.

~~~
justacomme555
I feel one better fix is to just add a small random wait from the time </html>
is served and the TCP socket is actually closed. I donnt think? this should
impact loads of the page when it is rendered in an html context.

~~~
yorwba
The delay should not be simply random, it would need to be carefully chosen to
make the load time distribution independent of the user loading the page.
Otherwise an attacker could just average multiple requests to get rid of the
randomness.

~~~
justacomme555
Youre right... the delay would basically have to be chosen dynamically to
enforce a universal page load time for all html documents on twitter.com

Still feels nicer than forcing a roundtrip

------
saagarjha
> We support a legacy version of Twitter (known internally as M2) that
> operates without the need for JavaScript. We needed to make sure our
> reloading solution didn't require JavaScript.

Ooh, I did not know this existed. It's nice that they've kept it alive!

------
Silhouette
I'm not normally one for meta-comments on HN, but reading the thread title
here freaked me out for a moment... I wish I could protect _my_ identity from
being associated with an attack against online privacy!

~~~
jobigoud
I thought it would be about how machine learning can identify you from your
silhouete in videos even if you wear makeup defeating face recognition.

------
TekMol
What is the point of showing a different page to a blocked user then to a
logged out user?

The blocked user can simply log out or switch to a private tab to see the
profile anyhow.

------
rauhl
> Tuesday, 18 September 2018

…

> _Recently [emphasis mine]_ we learned of a new technique for discovering the
> identity of logged-in users to online platforms including Twitter

…

> The issue was reported to us in _December 2017 [emphasis mine]_

This appears to be some new definition of ‘recently’ of which I was hitherto
unaware.

It’s definitely a clever attack, and definitely a clever set of fixes. But a
better phrase would have been ‘some time ago’ rather than ‘recently.’

------
iampims
I’m impressed by how quickly browsers implemented the sameSite cookie
attribute.

------
Operyl
So that explains why I’ve noticed twitter stopped working with view-source a
bit ago. I was curious as to why it required to redirect on itself, or a valid
referrer from itself, before letting me get anywhere.

~~~
VirenM
Another reason for the redirect would be to mitigate the relentless web
scraping which occurs. Some people just don't want to connect their apps with
keys.

~~~
Rjevski
Any malicious scraper can defuse this by sending the proper referrer header.

------
erikpukinskis
Wouldn’t a better solution be to flush some small part of the page immediately
(maybe just the html open tag) so that they get this immediate page load, and
then flush out the rest of the page when it’s ready? That way no timing is
leaked, but there’s still only one page load?

------
TorKlingberg
This type of vulnerability (Silhouette) seems absolutely terrible to protect
against. XSRF is bad enough, and now we need dummy pages reloading themselves
for basic user privacy? Is the SameSite attribute going to be enough to stop
these timing based information leaks?

------
X-Istence
SameSite is supported by many more browsers than just Chrome these days:

[https://caniuse.com/#search=SameSite](https://caniuse.com/#search=SameSite)

~~~
di
From the article:

> While we implemented the mitigation above, we started discussions with the
> major browser vendors regarding the SameSite cookie attribute. Once we
> shared the problem with them, they were keen to help. All major browsers
> have now implemented SameSite cookie support. This includes Chrome, Firefox,
> Edge, Internet Explorer 11, and Safari. This was an incredible effort in a
> very short timeframe, and the browser vendors deserve enormous credit for
> responding quickly.

------
chadwilken
Now that they have this fixed, I hope they are working on a solution for all
of the clone accounts that pose as Elon Musk or Charlie Lee and others.

