Evaluate web fingerprint
Now that we use Torbrowser patches (
Feature #5798), we can reconsider the browser fingerprinting issue.
We should evaluate the Tails web browser fingerprint.
- Extensions: FoxyProxy, Cookie Monster, You tube video downloader, download manager (not implemented yet), Adblock.
- Would we be ready to stick to or synchronize our add-ons with Torbrowser? (e.g Adblock is useful)
team: jvoisin, spriver?
Related to Tails -
#5 Updated by jvoisin 2015-10-11 06:22:01
Currently, the main issue that I see is AdBlock Plus, because it can super-easily be detected. Also, cookies blocking issued by CookieMonster can be detected by the website which has its cookies blocked.
Those are the two current main culprits in regard to fingerprinting that can be used to tell apart Tails and TBB users, and I don’t see any easy way to fix this, other than pushing either removing those extensions from Tails, or to push them into the TBB.
#10 Updated by cypherpunks 2017-01-08 08:13:53
- Tails currently, or will eventually, block access to
/dev/dri/through its AppArmor policy for security reasons.
- Math library fingerprinting can detect that Debian stable is likely in use, which points heuristically to Tails.
- The browser build is 32 bit (I believe this can be fingerprinted?), though Tails will use a 64 bit userland soon.
#11 Updated by intrigeri 2017-01-08 09:03:41
No, it’s about the default settings, and web fingerprinting by network attackers and admins of visited web sites.
> * Tails currently, or will eventually, block access to
/dev/dri/ through its AppArmor policy for security reasons.
Can you please clarify how this can be detected by the adversaries we have in mind?
> * Math library fingerprinting can detect that Debian stable is likely in use, which points heuristically to Tails.
Care to clarify how this can be done?
> * The browser build is 32 bit (I believe this can be fingerprinted?), though Tails will use a 64 bit userland soon.
Indeed, I expect that once we ship to 64-bit this will remove one thing that makes Tails different from most other Tor Browsers.
#12 Updated by cypherpunks 2017-01-08 11:05:02
> No, it’s about the default settings, and web fingerprinting by network attackers and admins of visited web sites.
For reference, the adversaries I am referring to are those who are intentionally trying to detect that a given Tor Browser user is also a Tails user, rather than an adversary who is retroactively checking the logs of another fingerprinting adversary (e.g. CloudFlare), or nosy sysadmins who have set nginx to an excessively verbose loglevel.
> > * Tails currently, or will eventually, block access to
/dev/dri/ through its AppArmor policy for security reasons.
> Can you please clarify how this can be detected by the adversaries we have in mind?
There are some CSS elements which are accelerated using hardware acceleration (unrelated to WebGL hardware acceleration), the kind which is not turned off just by disabling “enable hardware acceleration” in the UI, I believe. I don’t remember any specifics off the top of my head. Basically, performance fingerprinting of specific functionality, though I would bet that there are plenty of other ways to remotely detect whether or not Firefox has access to DRI nodes.
Of course, access to the DRI nodes can also make fingerprinting worse, due to GPU clock fingerprinting and other techniques, so it’s not like it’s just a trade-off between security and fingerprintability.
> > * Math library fingerprinting can detect that Debian stable is likely in use, which points heuristically to Tails.
> Care to clarify how this can be done?
High precision math libraries on different systems will give different results for some functions which can identify the operating system, and even different math library versions. See https://people.torproject.org/~gk/misc/MathHighPrecisionAPI.html for a PoC, and https://trac.torproject.org/projects/tor/ticket/13018 for the bug report.
It was suggested by mikeperry to ship the same version of
libm.so for all their Linux bundles in that bug report to mitigate this fingerprinting vector, in which case it would limit an adversary to only be able to tell that the Tor Browser user is a Linux user, but not that they are using the specific math libraries used by the version of Debian which Tails is based on at any given point in time.
> > * The browser build is 32 bit (I believe this can be fingerprinted?), though Tails will use a 64 bit userland soon.
> Indeed, I expect that once we ship to 64-bit this will remove one thing that makes Tails different from most other Tor Browsers.
Which also means Tails will be compatible with the official Tor Browser Sandbox which Yawning Angel made! Though that’s for another ticket (and plenty of testing).
#13 Updated by cypherpunks 2017-01-08 12:39:54
It might also be possible to use
resource:// URIs to discover whether or not a user is a Tails user, if the browser configs exist in any different location, or have been changed in any way from the upstream configs (e.g. current Tails disables autoupdate, which is detectable as these files are not protected like resources under
file://). The files can be read line by line, checksummed, uploaded remotely, etc. See https://browserleaks.com/firefox for an experimental PoC, and https://trac.torproject.org/projects/tor/ticket/8725 for the ticket.
#14 Updated by Kurtis 2017-01-19 03:34:23
Even with TBB’s font.system.whitelist strategy in place, sites can use JS to determine what operating system you are using, no? Can this be minimized in any way?
#16 Updated by intrigeri 2018-08-19 12:11:52
- Type of work changed from Research to Security Audit
Let’s assume that we don’t try to hide the platform (Tor Browser mostly gave up on that, see User-Agent in Tor Browser 8) and probably the fact we’re running Debian.
I’ve taken a look at our current delta and I think the main things that make Tor Browser in Tails different than Tor Browser on another Debian system are:
- uBlock Origin → the project has spoken and wants to keep it
pref("noscript.untrusted", "google-analytics.com");→ not sure why we still have this, I’m in favor of removing this part of our delta, that probably causes more problems than it solves
It’s also possible that some restrictions (e.g. to system-wide ressources) of our AppArmor policy make the browser’s fingerprint different. It would be interesting to research this.
But I’m not an expert at these things and IMO someone better skilled should look into our actual fingerprint, from an adversarial PoV => updating type of work.