[tbb-dev] The impossible fights on anti-fingerprinting

[Georg Koppen]

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=assigned&status=merge_ready&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tbb-fingerprinting-os&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20171023/87854805/attachment.sig>