Traffic fingerprinting issue
jutozex opened this issue · comments
Especially with the addition of Facebook rule, any user of this extension became unique in traffic fingerprints because most websites have many social media tools, especially the Like button.
You can see it for yourself, browse through some major news websites and check that the resources from facebook are loaded over the hidden service. Javascript doesn't even need to be enabled for this to happen.
Until this issue is solved, facebook rule should remain off by default. And anyone who enables it should disable right after they log out of or done with facebook.
Apart from anonymity issues, it could generally slow down browsing over Tor Browser.
Solution:
If HTTPS Everywhere has an option to ignore redirections for third party requests (resource requests from different domains), we should use that. Or report this issue upstream and/or get this fixed.
I mean if the url bar is facebook.com, it should redirect to the hidden service but it should not redirect the like button on all websites.
I think this should apply for all of our rules, HTTPS Everywhere was meant to encrypt all requests from all websites, not anonymize them. Traffic analysis wasn't a concern for HTTPS Everywhere, but it is for us.
For darkweb-everywhere, we must stop redirections on third-party requests.
Otherwise, we're using Tor with a "darkweb-everywhere user" label which could easily lead to deanonymization.
The alternative solution is to get these rules merged into Tor Browser so every Tor user would be using them. But even then people would prefer facebook rule disabled by default to prevent slowing down webpages. So even this is not a real solution.
wouldn't something like EFF's privacy-badger solve this issue?
No, it would make it worse. Things like that change the browser behavior and make you unique and actually trackable when using Tor.
The threat model here does not include advertising agencies, but global adversaries such as NSA.
Shoot, looks like I forgot to reply to this thread yesterday. It's been sitting in my email drafts...
Here's what I originally wrote:
"Thanks for the great analysis on this. Chris and myself have been talking about how best to deal with this issue and feel that we should add a disclaimer to note the side effects of using our extension. In my opinion, a user of our rules is expecting sites to redirect for them / be enabled by default. This is a tricky issue, and we are balancing between security, expected behavior, and convenience here. I'm open to being persuaded however, so a decision hasn't been set in stone yet.
It's also worth noting that this doesn't just apply to Facebook. Another example can be img.bi, which allows for embeds into other web pages. These would also be loaded over the .onion if our rules are loaded, fingerprinting as one of our users. Granted img.bi isn't as huge as Facebook in use, but it's another example of this behavior.
I'd like to try out that exclusion rule you found, but I'd need some time to hack away on this, and I don't see any spare time coming my way until at least next week
As for merging this into the Tor Browser, this would have to be done by the EFF since they are the maintainers of HTTPS Everywhere. If this happens, it would be ideal since we would have a much larger percentage of users, making the use of these rules a lot less unique. Yan (@diracdeltas) mentioned this on the https-everywhere list about a month ago, with the intention of making an "onion" toggle switch, but I haven't seen or heard anything relating to this. Anyone want to pester them for an update? :)"
As for privacy badger, it could stop the Facebook like buttons, trackers, etc. from being loaded into the page, at least as far as I understand how the extension works. (Noscript in the TBB could do the same thing too, in theory). But like juto said, it's not ideal since this makes your browser much more identifiable.
AFAIK in one of the last updates of Tor Browser there was implemented a technology which separates third-party requests and sends them through a new Tor connection.
So possibly this affects this issue or even solves it, doesn't it?
I think you're talking about this? https://blog.torproject.org/blog/tor-browser-45-released#Privacy
If so, I feel it would close this ticket. It would still be obvious to the HS operator that someone has this installed (who else would be requesting scripts and css over a HS?).