1849864 - HTTPUserAgent RFPTarget still active with Tracking Protection disabled

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Kestrel]

Attachment: Spoofed useragent with Tracking Protection disabled

STR:

1. Enable FPP with all RFPTargets on latest Nightly 118.0a1 on Ubuntu 23.04.
   privacy.fingerprintingProtection = true
privacy.fingerprintingProtection.overrides = +AllTargets
2. Visit https://browserleaks.com/ip.
3. Disable Enhanced Tracking Protection (ETP) for the site.

Expected:
Real useragent.

Actual:
Useragent reports as "Windows NT 10.0" instead of Linux.

HTTPUserAgent RFPTarget appears to still be active despite FPP being disabled via ETP. Other RFPTargets appear to be correctly disabled, including NavigatorUserAgent.

Comment 1

[Tim Huang[:timhuang]]

Attachment: Bug 1849864 - Update the userAgent header once the AntiTracking Info is updated. r=tjr,#necko,jesup

The userAgent was decided when the channel was created, but the channel
hasn't known about whehter it should exempt fingerprinting protection at
the moment. To properly set the userAgent, we need to update the
userAgent header once we know the AntiTracking info.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b595a7dfd41b
Update the userAgent header once the AntiTracking Info is updated. r=tjr,necko-reviewers,jesup

Comment 3

[Norisz Fay [:noriszfay]]

Backed out for causing multiple failures

Backout link

Push with failures

Failure log 1 // Failure log 2 // Failure log 3 // Failure log 4

Comment 4

[Tim Huang[:timhuang]]

Attachment: Bug 1849864 - Don't recalculate the userAgent header if it has been modified. r?tjr!,jesup!,#necko

The userAgent header can be modified in several ways, such as using the
header field to set a custom userAgent header for a fetch request. We
want to preserve the custom header, so we shouldn't recalculate the
userAgent header if it's been overridden after the channel was created.
Otherwise, the custom header won't work.

Depends on D196953

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8a5a6b997e2a
Update the userAgent header once the AntiTracking Info is updated. r=tjr,necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/c57d859580d0
Don't recalculate the userAgent header if it has been modified. r=tjr,jesup,necko-reviewers,devtools-reviewers

Comment 6

[Iulian Moraru]

Backed out for causing multiple failures.

• Push with failures

• Failure log for failures on browser_net_copy_headers.js

• Backout link

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6c096a3d29c7
Update the userAgent header once the AntiTracking Info is updated. r=tjr,necko-reviewers,jesup
https://hg.mozilla.org/integration/autoland/rev/15f43f43c82c
Don't recalculate the userAgent header if it has been modified. r=tjr,jesup,necko-reviewers,devtools-reviewers

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/6c096a3d29c7
https://hg.mozilla.org/mozilla-central/rev/15f43f43c82c

Comment 9

[Dennis Schubert [:denschub]]

We have received a WebCompat regression report caused by this patch. I've linked it in the see-also field for now, but I'm not going to file a regression bug for this. As I explained in more detail in this comment, this looks like some server-side fingerprinting going horribly wrong, and unless we have evidence of this breaking more than this one site, let's try the outreach route first. I'm leaving this comment here so that if we run into this regression again, the person doing the analysis there will have a better time. :)