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.

#6 Updated by intrigeri 2015-10-12 05:40:18

> Also, cokkies blocking issueed by CookieMonster can be detected by the website which has its cookies blocked.

We’re not shipping CookieMonster since Tails 0.23.

#10 Updated by cypherpunks 2017-01-08 08:13:53

I assume the threat model is only for people who have JavaScript disabled? It is easy to tell if someone is using Tails (even with Adblock Plus removed, etc.) if JavaScript is enabled, for a few reasons:

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

I just want to confirm that the assumption is not that (active) fingerprinting can be fooled into being confident that a given browser is running on Tails, if JavaScript is enabled. Passive fingerprinting or scriptless fingerprinting probably won’t be able to tell after plugins etc. are synchronized.

#11 Updated by intrigeri 2017-01-08 09:03:41

> I assume the threat model is only for people who have JavaScript disabled?

No, it’s about the default settings, and web fingerprinting by network attackers and admins of visited web sites.

> It is easy to tell if someone is using Tails (even with Adblock Plus removed, etc.) if JavaScript is enabled, for a few reasons:

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

intrigeri wrote:
> > I assume the threat model is only for people who have JavaScript disabled?

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

> > It is easy to tell if someone is using Tails (even with Adblock Plus removed, etc.) if JavaScript is enabled, for a few reasons:
>
> > * 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

Oh yeah, and of course there’s the fact that the date format which JavaScript provides gives away that the platform is Linux, see https://trac.torproject.org/projects/tor/ticket/15473. Additionally, the list of included/whitelisted fonts differ between Linux and Windows (e.g. MSPGothic is included under Windows, but cannot be included under Linux for licensing reasons. See https://trac.torproject.org/projects/tor/ticket/20820 for a problem caused by the different font support between platforms). There are also HTML5 features which are platform-specific (see https://trac.torproject.org/projects/tor/ticket/13543). While these don’t specifically point to the user being a Tails user, it does reduce the anonymity set a bit (i.e. they can only hide among other Linux users, not among all users of Tor Browser).

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

Is the fact that the list of included/whitelisted fonts differs between Tor Browser users in Linux and Windows even solvable? I’m assuming that the amount of preloaded fonts on the OS don’t have enough overlap between the two operating systems. I hadn’t heard of this issue before, but javascript on, this site demos how JS can easily determine what kind of fonts your system has preloaded. https://arthuredelstein.github.io/tordemos/enumerate-fonts.html

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?