Description

Proposal: Treat anti-fingerprinting bugfixes like any other security bugfix with regards to prioritization and release management.

For instance, when an anti-fingerprinting fix lands in git, whether as a Tor Button update or as a mere Tor Browser default pref change, this should trigger a new Tor Browser Bundle release incorporating the fix, even if no other component needs updating.

Deanonymizing users through fingerprint leaks is becoming a realistic threat as the advertising industry consolidates and transforms itself into a tracking industry offering advertising as a sort of higher layer service. And we should assume that all kinds of other adversaries are already closely watching the tbb-fingerprinting tag.

Child Tickets

Oldest firstNewest firstThreaded

Show commentsShow property changes

Change History (4)

In a way, fingerprinting bugs are even more urgent than other security bugs: If you're worried as a user about a conventional security bug, you can backport the fix locally and use that until there's an upstream release. Whereas locally backporting an anti-fingerprinting bugfix will, perversely, make you more fingerprintable.

I am not convinced that every fingerprinting fix should trigger a new release. That might be an idea worth thinking about for high-entropy attributes but not all (or better: not much) fingerprinting attributes are of this kind.

Evaluating a bug's severity would involve writing a custom-tailored, robust to the point of almost being weaponized, fingerprinter. Assuming that TBB development had the manpower to do that, then after even more days spent on that we find out that it really is serious. Oops...

I feel like the question "Does this fingerprinting bug really have high entropy?" is analogous to "Does this use-after-free or whatever really give someone remote code execution?" in that it may usually be more realistic to err on the side of caution, assume "yes", and just start the release build.