privacy.resistFingerprinting breaks TikTok video search on Linux due to OS mismatch in UA between HTTP Header and Navigator
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | fix-optional |
firefox111 | --- | wontfix |
firefox112 | --- | wontfix |
firefox113 | --- | fix-optional |
People
(Reporter: ke5trel, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [domsecurity-backlog1])
Attachments
(1 file)
45.86 KB,
image/png
|
Details |
STR:
- On Ubuntu 22.10, set
privacy.resistFingerprinting = true
. - Visit https://www.tiktok.com/search/video?q=test.
- 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•1 year ago
|
||
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•1 year ago
|
||
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•1 year ago
|
||
Set release status flags based on info from the regressing bug 1509829
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Caused by the combination of two RFPTargets, HttpUserAgent
and NavigatorUserAgent
. Disabling either of them avoids the issue.
Comment 5•1 year ago
|
||
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)
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•1 year ago
|
||
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•1 year ago
|
||
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•1 year ago
|
||
... and
NavigatorUserAgent
. Disabling either of them avoids the issue.
navigator.userAgent
always mirrors the HTTPUser-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?)
Description
•