1826098 - privacy.resistFingerprinting breaks TikTok video search on Linux due to OS mismatch in UA between HTTP Header and Navigator

Status: RESOLVED DUPLICATE of bug 1840385

(Core :: DOM: Security, defect, P3)

Description

[Kestrel]

Attachment: Error page shown when searching TikTok with RFP

STR:

1. On Ubuntu 22.10, set privacy.resistFingerprinting = true.
2. Visit https://www.tiktok.com/search/video?q=test.
3. Solve the sliding puzzle.

Page displays:

Something went wrong
Sorry, something wrong with the server, please try again.

• Canvas extraction icon appears but permission is not required.
• RFP domain exception for *.tiktok.com works.
• Does not occur on Windows.
• Changing UA to Linux with the extension "User-Agent Switcher and Manager" works.

Comment 1

[Thorin [:thorin]]

the HTTP header spoofing to two OSes (windows/android) should be put behind a build flag for Tor Browser and this has been discussed before - I consider this a duplicate of Bug 1610762 (which is bit of a catchall bug for numerous sites effected by this spoof for mac/linux)

when we break web standards we can expect breakage - this is fine for Tor Browser if they want only two OSes in headers (for reasons) - but for Firefox makes no sense as 1) you can't hide the OS, not even passively, and Firefox users are not likely to bounce around the internet without JS enabled and 2) Firefox has a much larger crowd (if crowds are required) to reduce entropy. The threat model is not the same, and we're just alienating potential users

tom, richard - can we please put this HTTP header spoof behind a build flag, thanks

Comment 2

[Tom Ritter [:tjr]]

I don't think it will be a build flag, but we will be providing a better user experience for this and similar issues.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1509829

Comment 4

[Kestrel]

Caused by the combination of two RFPTargets, HttpUserAgent and NavigatorUserAgent. Disabling either of them avoids the issue.

Comment 5

[Thorin [:thorin]]

unless I am missing something here, RFP only reports windows in HTTP headers (for linux/mac/windows), not navigator, so disabling NavigatorUserAgent shouldn't make a difference (at least not in regards to OS spoofing)

Comment 6

[Kestrel]

HttpUserAgent on its own causes both the Header and Navigator to appear as Windows. When combined with NavigatorUserAgent, the Header is Windows and the Navigator is Linux. Tiktok search fails when the Header and Navigator OS do not match.

Comment 7

[Thorin [:thorin]]

HttpUserAgent on its own causes both the Header and Navigator to appear as Windows

IIUIC, then that's a bug. Because we explicitly decided to always use 4 OSes in navigator to reduce breakage. I say bug, and by that I mean in how these/this get flipped in RFP targets, because without this (targets) linux/mac has always reported linux/mac in navigator. HttpUserAgent should do what it's name says and only affect HTTP headers

Comment 8

[Tom Schuster (MoCo)]

navigator.userAgent always mirrors the HTTP User-Agent header, so when you only overwrite the header, but not the navigator property that is the default behavior you get. That is not a bug. Toggling individual RFPTargets producing unwanted results is not something we worry about too much.

Comment 9

[Thorin [:thorin]]

... and NavigatorUserAgent. Disabling either of them avoids the issue.

navigator.userAgent always mirrors the HTTP User-Agent

"always mirrors" ... ahh, interesting. IDK that. Disabling NavigatorUserAgent also affects the HTTP header, apparently. Do you not think that having two targets for one protection is confusing? Or having one target affect another target? Rhetorical.

HttpUserAgent on its own causes both the Header and Navigator to appear as Windows

So a user targeting NavigatorUserAgent to solve the mismatched header/navigator ends up being Windows on Linux/Mac - which means we're still spoofing, which is the opposite of turning it off. Just saying :) And we know from experience that reporting as Windows in navigator on non-windows platforms causes breakage - which is why it was changed to four OSes in the first place.

Toggling individual RFPTargets producing unwanted results is not something we worry about too much.

Somewhat agreed ... pref.name.do.not.use.targets.list.here.be.dragons.etc.use.at.your.own.risk :) Just saying that anything relaxed in compat we should care about - but of course this is not a FPP item, and probably an outlier, and if when we remove it (http header as windows on mac/linux) on Firefox, then it's no longer an issue (or a target?)

Comment 10

[Pier Angelo Vendrame]

Downstream in Tor Browser we have a patch to add a pref to optionally not spoof the OS in the user agent, but it is disabled by default (the main reason is that I don't know how important this protection is).
Would it be interesting for Firefox to be able to do the same? I guess an RFPTarget might be preferred, but would one be worth for this case? Or maybe should we rework the two existing ones?
Or do you think spoofing the OS in the header does not make sense anymore?

Comment 11

[Tom Ritter [:tjr]]

Disabling RFPTarget::HttpUserAgent will stop spoofing the UA Header entirely. We could in theory add another one that would spoof everything but the OS (although I'm not sure what that would actually spoof. Minor Version maybe?)

Or do you think spoofing the OS in the header does not make sense anymore?

The original reasoning for continuing the spoofing is that UA logging is pervasive so lying about something that winds up in logs everywhere seems advantageous. Sites can log the UA exposed in JS, but it's not pervasive. But the point of fingerprinting, in my mind, is to defend against an attacker that wants to correlate your visit with possible previous visits same or cross-site, or target you specifically for some sort of attack. Spoofing the OS in the UA Header doesn't help in either of those cases.

Comment 12

[Pier Angelo Vendrame]

(In reply to Tom Ritter [:tjr] from comment #11)

Disabling RFPTarget::HttpUserAgent will stop spoofing the UA Header entirely. We could in theory add another one that would spoof everything but the OS (although I'm not sure what that would actually spoof. Minor Version maybe?)

For desktop it spoofs also the architecture (it will say x64/x86_64 also on 32-bit builds).

Or do you think spoofing the OS in the header does not make sense anymore?

The original reasoning for continuing the spoofing is that UA logging is pervasive so lying about something that winds up in logs everywhere seems advantageous. Sites can log the UA exposed in JS, but it's not pervasive.

Yep, I agree, and that's the main reason for which not so long ago I insisted for not making this the default.
We asked for feedback a while ago in an alpha release post, but we didn't get much (apart from the reminder that the OS will become visible to an eavesdroppers during the HTTPS-Only probe, but probably it's a problem only for Tor, that hides the TCP fingerprinting by using streams).

But the point of fingerprinting, in my mind, is to defend against an attacker that wants to correlate your visit with possible previous visits same or cross-site, or target you specifically for some sort of attack. Spoofing the OS in the UA Header doesn't help in either of those cases.

Makes sense, thanks.

Comment 13

[Thorin [:thorin]]

resolved in Bug 1840385