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

Status: NEW

(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?)