Discussion: UA: window vs iframe

[Thorin-Oakenpants]

snip

[crssi]

Not only different.
Under iframe.contentWindow you get the real browser you are using.

[BananaMangoFestival]

The latest version of Random Agent Spoofer now spoofs also the iframe, you have to enable script injection

[nodiscc]

I have just run the tests mentioned above (mostly http://www.darkwavetech.com/fingerprint/fingerprint_truebrowser.html, http://www.darkwavetech.com/fingerprint/fingerprint_os.html), using various spoofed User-Agent strings (real browser/version/OS is Firefox 53 on Linux 64 bits):

• Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0 (commented-out value in user.js, same value as Tor browser)
• Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 (random Google Chrome UA string)

Note that javascript has to be enabled for the test to run.

Results:

• Spoofed Firefox UA string: Firefox on Windows 7|32 bits
• Spoofed Chrome UA: Firefox on Windows 7|32 bits

While fingerprinting tests can successfully uncloak a browser pretending to be a different browser, there is no evidence that it can detect 1. a spoofed operating system substring 2. A spoofed version substring.

Buty anyway I suggest that we leave the User-Agent pref commented out. If you need to defend against advanced fingerprinting techniques there is a chance that you should be using Tor browser directly in the first place (UA string only adds a small amount of entropy). Spoofing UA also has indirect disadvantages (websites nagging you about your browser being too old/unsupported, disabled functionality such as on AMO, etc.)

I think that this issue can be closed.

[pyllyukko]

I see that general.buildID.override is already there, was it tested as effective? Also I think that it should be commented out and moved alongside the UserAgent spoofing section, since it makes no sense to spoof one and not the other. @pyllyukko ?

Yes, it was tested. See here. We're leaving it there.

The thing I worry about in this, is that when crafting client-side exploits against the browser, an attacker can practice with the same exact version and get to a whole different level of precision to perfect the exploit.

Security is never perfect and as @Thorin-Oakenpants so often points out, that there are still ways to FP the browser, which of course is true. But it's about raising the bar and making the attackers work harder. This applies to privacy as well... even though it doesn't mean squat against advanced FP techniques, it still matters.

Also see the discussion in commit 35b9892.