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.

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

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.

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.

The article says certain extensions block the referrer, thus producing the manual link to click. I don't believe Safari Extensions can muck with the referrer that way, in terms of affecting resource loads I think it's limited to allow/deny. And besides, Twitter never showed me a manual link, it was just a completely blank page.

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.

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.

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

Same on Android, twitter.com works half of the time on my phone, the other half I have a blank page with only the top rendered. I don't know what they are doing exactly but it clearly does not work well.

Upgrading to Safari 12 fixed it for me too. Not sure why it was broken on Safari 11.

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

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!

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.

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.

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

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

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.

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.

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

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?

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?

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

https://caniuse.com/#search=SameSite

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.

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.