Closed Bug 1489903 Opened Last year Closed Last year
.useragent .override ignored when privacy .resist Fingerprinting=true
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180905224245 Steps to reproduce: Using "62.0 (64-bit)" or the current nightly "64.0a1 (2018-09-09) (64-bit)", set general.useragent.override="ExampleUserAgent/1.0.0" and privacy.resistFingerprinting=true in about:config. Actual results: User-Agent header sent in the requests is "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" not "ExampleUserAgent/1.0.0". Expected results: I contend that if general.useragent.override has a non-default value, then it should be sent as the User-Agent request header, regardless of the setting of privacy.resistFingerprinting. Although setting a custom User-Agent can make fingerprinting easier, it can also make fingerprinting more difficult (e.g. spoofing a more common platform) and is not inherently in conflict with fingerprint resistance. Further, I think that the users should have the ability to make that trade-off for themselves. Respecting general.useragent.override does not prevent the user from using the privacy.resistFingerprinting default if they choose. The current behavior forces the user to choose between all of the benefits of a custom User-Agent and the benefits of privacy.resistFingerprinting (and limitations of User-Agent changer add-ons). If this change is acceptable, I'd be willing to submit a patch (although it may take me a while to figure out) or do other legwork to make it happen. Thanks for considering, Kevin This is related to https://trac.torproject.org/projects/tor/ticket/26146
This is not a bug, but by design. RFP is an all or nothing buy in.
Thanks for the response. I'm not familiar with the processes. Can you point me to the RFP? Can the RFP be changed or a subsequent RFP be submitted to amend this part of the design? Is it possible to discuss the particular behavior of ignoring general.useragent.override on its merits?
RFP is just shorthand for privacy.resistFingerprinting As part of the Tor Uplift, it is important that all users present the same fingerprint (where possible) or a smaller subset of values (eg inner window measurements, timing attacks, screen co-ordinates) or disable APIs (if unavoidable), in order to lower entropy. Bypassing the general.useragent.override pref is part of that. Anyone with an existing value for that pref would stand out (if it differed), and defeat the whole purpose of RFP (which is essentially an enforced FP for all users). If users could easily change values willy nilly, then the whole concept falls apart. TBB (Tor Browser Bundle) can do as they like, but the purpose for the uplift is to reduce code changes at their end (and as an important privacy/anti-tracking feature for Firefox users). I take it this is all about the UA spoofing platform to 4 OS's (Windows, MacOS, Android, Linux) with Linux as the fallback. For Mozilla, this would most likely be WONTFIX (I know that's not what you're asking, falling back to one OS, Windows) because it causes too much breakage (keyboard issues on MacOS, andoid being served desktop pages, etc). This is the main reason IMO, because RFP uptake is important (when it becomes front facing). The other reason is that there are too many ways for websites to detect your real OS (which is somewhat less of a threat on TBB). Mitigating the pitfall of general.useragent.override was a deliberate decision, and you won't find any change of heart here. Firefox users who really want to spoof their UA differently to RFP, can always use an extension (because the extension will be the last to modify it). I would not recommend this, as it would potentially make them stand out (it might not take many fingerprint values to establish an RFP user - eg set viewport sizes + timezone). I need info'ed Tom Ritter, maybe he can explain it better. Or Arthur Edelstein.
Thanks for the thorough explanation! privacy.resistFingerprinting offers several protections beyond User-Agent spoofing, which can be useful to users with a configured U-A. I do agree that there is risk of users making bad decisions, particularly in light of OS network stack fingerprinting, but if a user chooses to configure general.useragent.override, I think they have accepted the risk. Even in TBB, it's possible to distinguish user-configured general.useragent.override from the default value. Although browser extensions can work for spoofing U-A, they add a lot of complexity and implementation issues. (e.g. https://gitlab.com/ntninja/user-agent-switcher/issues/37 for favicon requests, maybe fixable after Bug 1453751) There are clear disadvantages compared to general.useragent.override. I agree Tor Uplift is an overriding concern. If TBB would have to carry a patch to revert a change resulting from this bug, I agree the change shouldn't be made. However, I think TBB should also honor user-configured general.useragent.override. Perhaps we should wait until https://trac.torproject.org/projects/tor/ticket/26146 shakes out to see how TBB decides to handle it?
(In reply to Kevin Locke from comment #4) > but if a user chooses to configure general.useragent.override, I think they have accepted the risk But do they really know the risk? This pref merely changes the value of the UA "string". It does not fix underlying navigator leaks (I'm pretty sure platform leaks here). Not to mention other inconsistencies with other parts of the UA should values be changed. It's an old, incomplete "solution" that doesn't deserve consideration and promoting it's use above RFP is irresponsible, IMO.
Hm, this is a tricky one. We'll talk about this offline for sure. Simon gave a lot of background: He's right that our policy has been "We don't allow users to selectively opt out of RFP protections." However, we don't make RFP override everything: one can set other preferences that change how your Resist Fingerprinting 'profile' appears to the web and thus make you unique. Disabling features is the most straightforward, but there's also some other more subtle ones. Setting the User Agent header seems, to me, to be an unusual case we should consider more carefully. For the intended purpose of wanting to opt-out of a specific RFP protection - yea I would agree that's probably a WONTFIX. But there may be other use cases that make this desirable regardless. For example: Maybe I need to change my user agent to bypass some detection script or use it to narrow down a bug in a website. Are there others? The ability to use an extension to change the UA; however, is a big swing of the pendulum towards leaving it as-is. Functional bugs in the extensions ability to do that should be filed and fixed, although I know that's not a very satisfying answer (and I know there is a blocklist of sites extensions cannot modify.)
(In reply to Kevin Locke from comment #7) > > One other concern I have is that general.useragent.override has existed for > a long time and is widely documented across the web. I am concerned that > non-negligible amounts of developer time will be wasted when > general.useragent.override fails to change the User-Agent header and > developers have to figure out why (as I did before filing this bug). > Perhaps if there were a warning (either upon changing g.u.o/RFP or in the > Browser Console) that could be reduced? I think the idea of a warning in the browser console or elsewhere providing a notification that privacy.resistFingerprinting overrides another pref is a really good idea. A similar approach might be a general notification whenever privacy.resistFingerprinting is toggled, that lists all of its properties in the browser console (including mentioning general.useragent.override).
See Also: → 1490728
We discussed this at the meeting today. You explained the situation very well. In general, we don't want to allow bypasses of RFP, and in fact want to do a better job about overriding other prefs that we need to in order to do so. Your note about discoverability is good though, and I opened Bug 1490728 for that; but it's likely that won't be done if/until we get much closer to shipping Fusion. Especially given that one can accomplish this with a WebExtension, we're going to WONTFIX this. If you find that the WebExtension is incapable of modifying the UserAgent, you can file a new bug for that, and we'll consider the situation there.
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
Sounds good. Thanks, to you and everyone who commented, for thoughtfully considering and discussing! I'll follow Bug 1490728 for updates on the discoverability.
11 months ago
See Also: → 1499478
You need to log in before you can comment on or make changes to this bug.