Tom Ritter:

<mozilla hat>

As we add more and more coverage to privacy.resistFingerprinting in FF Nightly and Beta, we're getting more and more breakage reports. This is great. And it's showing us a few places we should think about more deeply. We have a list we're collecting here: https://wiki.mozilla.org/Security/Fingerprinting#Fingerprinting_Breakage

1. User Agent

We round the user agent of the browser to the previous ESR version. So FF 57 appears as FF 52.

This breaks Add-On installation: https://bugzilla.mozilla.org/show_bug.cgi?id=1394448 Addons.Mozilla uses the User-Agent header to detect if the user is able to install a given addon and will or will not enable the install button based on that.

However, does spoofing the major version of the browser actually work? I would argue: no. A website that wants to learn what version of Firefox you're using can use feature detection. Every major release we're adding CSS stuff, creating or enabling DOM apis by default, and probably changing some subtelties of error messages.

Spoofing the minor version is still valuable; but we're considering reporting the correct major version. What do you think?

I guess the main question to answer is: What's the idea behind choosing the browser version from the Firefox 52 ESR User Agent?

1) Is the rationale to blend in with Tor Browser users? 2) Is the rationale to blend in with Firefox ESR users?

When we switch to a new ESR we adapt the User Agent with the argument that we don't support older ESR versions anymore and just stick with the one the current version delivers (thus, there is no version spoofing taking place). I can see an argument for doing the same with Firefox in case Mozilla is not caring about 1) or 2).

2. OS

We report the OS as Windows on Mac and Linux.

This breaks google apps on mac: keyboard shortcuts are not recognized because Windows is looking for a key modifier that isn't there. https://bugzilla.mozilla.org/show_bug.cgi?id=1405810

It also gives desktop pages on mobile: https://bugzilla.mozilla.org/show_bug.cgi?id=1404608

Yes, this is the reason why we won't ship a desktop UA on mobile.

But is spoofing the OS even possible? You guys don't reward for it in the bug bounty. I found your list of OS-fingerprinting bugs:

Actually, I think I rewarded bugs for issues with that. But you are right our policy excluded this area. For a reason. :)

https://trac.torproject.org/projects/tor/query?status=accepted&status=as...

Not sure if it is possible but it's definitely hard and as there are a bunch of things revealing more entropy which is why we put it more or less on the backburner.

Of those, I'm guessing the Math routines are probably the hardest. Also, this doesn't affect Tor Browser, but it does affect Firefox: you can passively (or actively) fingerprint the OS by TCP/IP characteristics: https://bugzilla.mozilla.org/show_bug.cgi?id=1409269

So I'm wondering, are there other OS-level fingerprinting vectors that seem unsolvable that don't have tickets for them? What do you think of reporting the correct OS (in FF at least), since it seems like we wouldn't be able to hide it anyway?

I think that's not unreasonable as a stop-gap while thinking about better solutions, especially given the breakage you encounter.

Georg

For both of these Tor Browser will be able to do whatever it wants, since this data is all controlled by prefs; but we'd value your thoughts on these things for the FF use case.

-tom _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev