5 ms·

Protecting user identity against Silhouette

99 points by stablemap 8y ago

Operyl 8y ago
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 8y ago
  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 8y ago
    Any malicious scraper can defuse this by sending the proper referrer header.
iampims 8y ago
I’m impressed by how quickly browsers implemented the sameSite cookie attribute.
saagarjha 8y ago
> 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!
eridius 8y ago
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).
- X-Istence 8y ago
  Upgrading to Safari 12 fixed it for me too. Not sure why it was broken on Safari 11.
- gcb0 8y ago
  Sad that people today think that not flashing for a brief instant some text on a redirect page trumps usability on people that have browsers that might not follow the redirect correctly. Had they put a "<a href=twitter.com/ok>Twitter.com</a>" instead of a blank page, they (and their users) wouldn't have to worry about buggy browsers.
- justacomme555 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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
X-Istence 8y ago
SameSite is supported by many more browsers than just Chrome these days: https://caniuse.com/#search=SameSite https://caniuse.com/#search=SameSite
- di 8y ago
  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.
rsj_hn 8y ago
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.
rauhl 8y ago
> 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.’
Silhouette 8y ago
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 8y ago
  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 8y ago
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.
TorKlingberg 8y ago
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?
chadwilken 8y ago
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.
erikpukinskis 8y ago
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?

99 points by stablemap 8y ago

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 8y ago
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 8y ago
  Any malicious scraper can defuse this by sending the proper referrer header.

iampims 8y ago

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

saagarjha 8y ago

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

eridius 8y ago

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

X-Istence 8y ago
Upgrading to Safari 12 fixed it for me too. Not sure why it was broken on Safari 11.
gcb0 8y ago
Sad that people today think that not flashing for a brief instant some text on a redirect page trumps usability on people that have browsers that might not follow the redirect correctly. Had they put a "<a href=twitter.com/ok>Twitter.com</a>" instead of a blank page, they (and their users) wouldn't have to worry about buggy browsers.
justacomme555 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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

X-Istence 8y ago

SameSite is supported by many more browsers than just Chrome these days: https://caniuse.com/#search=SameSite https://caniuse.com/#search=SameSite

di 8y ago
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.

rsj_hn 8y ago

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.

rauhl 8y ago

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

Silhouette 8y ago

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 8y ago
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 8y ago

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.

TorKlingberg 8y ago

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?

chadwilken 8y ago

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.

erikpukinskis 8y ago

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?