New low cost traffic analysis attacks and mitigations

Patrick_mobile · January 3, 2020, 11:02pm

Agreed. Anything that requires to open a port in any users local physical modem/router is going to fail. Most won’t be able to do that. At best for advanced users.

Which options are left?

Snowflake? Is that a “real bridge” for the purpose of this issue that helps defeating this attack?

Does that contradict Tor Entry Guards - Whonix ?

The Design and Implementation of the Tor Browser [DRAFT] contradicts this.

No filters Site-specific or filter-based addons such as AdBlock Plus, Request Policy, Ghostery, Priv3, and Sharemenot are to be avoided. We believe that these addons do not add any real privacy to a proper implementation of the above privacy requirements, and that development efforts should be focused on general solutions that prevent tracking by all third parties, rather than a list of specific URLs or hosts. Implementing filter-based blocking directly into the browser, such as done with Firefox’ Tracking Protection, does not alleviate the concerns mentioned in the previous paragraph. There is still just a list containing specific URLs and hosts which, in this case, are assembled by Disconnect and adapted by Mozilla. Trying to resort to filter methods based on machine learning does not solve the problem either: they don’t provide a general solution to the tracking problem as they are working probabilistically. Even with a precision rate at 99% and a false positive rate at 0.1% trackers would be missed and sites would be wrongly blocked. Filter-based solutions in general can also introduce strange breakage and cause usability nightmares. For instance, there is a trend to observe that websites start detecting filer extensions and block access to content on them. Coping with this fallout easily leads to just whitelisting the affected domains, hoping that this helps, defeating the purpose of the filter in the first place. Filters will also fail to do their job if an adversary simply registers a new domain or creates a new URL path. Worse still, the unique filter sets that each user creates or installs will provide a wealth of fingerprinting targets. As a general matter, we are also generally opposed to shipping an always-on Ad blocker with Tor Browser. We feel that this would damage our credibility in terms of demonstrating that we are providing privacy through a sound design alone, as well as damage the acceptance of Tor users by sites that support themselves through advertising revenue. Users are free to install these addons if they wish, but doing so is not recommended, as it will alter the browser request fingerprint.

Add uBlock Origin to the Tor Browser:

Network fingerprint from internet service provide (ISP) perspective. Not web fingerprint from website perspective.

Users would probably love ad blocking by default. So would I. We can consider ad blocking for usability too.

Ad blocking would worsen the fingerprint, so goes the argument. Is that really so? I speculate this argument might be mostly based authority and unrealistic expectations for future TBB improvements. But is it backed by actual knowledge, testing, data? Measurable worse?

See tbb-linkability [archive] and tbb-fingerprinting [archive]. I speculate these bugs might not br fixed soon, other similar issues are identified meanwhile. The worse fingerprint might not matter as TBB might never be good enough for ad blocking to matter?

Problem is that it is an “inside” Tor Browser issue. Once Tor Browser was inside modified, all Tor Browser issues would be blamed on Whonix. Similar to add Tor Browser first startup popup to ask whether security slider should be set to safest

“Inside” Tor Browser modifications are fragile as add Tor Browser first startup popup to ask whether security slider should be set to safest has shown. Tails cannot be compared much? Whonix / Tor Browser can be upgraded anytime. Tails not so much since its mostly release based updated?

quote Tips on Remaining Anonymous