How do you change the user agent string? I’d like to know for testing purposes. In Firefox you can set general.useragent.override but this doesn’t have any effect in the Tor Browser, I don’t know why.
I don’t know why
RFP (privacy.resistFingerprinting) in code ignores these override prefs. RFP is locked in Tor Browser stable
For testing you can use alpha and flip RFP, or you can use an extension - note that extensions lack the APIs to properly do this - and besides, you cannot hide the engine, version or OS due to feature detection.
Thanks for explaining!
I’m curious if locking RFP in stable actually has security benefits in code or if this is just the browser being overly protective? (But it’s not important, so don’t worry if you don’t know the reason.)
I’ll try with the alpha build then. Good to see there are sigs provided for that! Too many projects don’t include sigs for their alpha builds.
Yes, this is actually want I want to test, there’s a website refusing to work because it thinks my browser is too old, and I want to test if it is actually doing feature detection or just looking at the user agent!
so don’t worry if you don’t know the reason
I am the reason 
We do not want users to be able to flip off something so fundamental to anonymity
there’s a website refusing to work because it thinks my browser is too old
You can just test current Firefox then. Set the userAgent to something old and see if it breaks. If you’re on windows you can use a portable apps Firefox old version and set the override agent to something new as a reverse test.
However, why would you be using an old Firefox. If you mean because it’s ESR, there’s no workarounds for that (testing), we just have to wait for ESR end-of-life
Can I ask what the website is?
Edit: TB14 alpha based on ESR128 should be out this week
2 Likes
We locked RFP because some users disabled it just for getting the dark theme or other minor features that RFP breaks without realizing all the stuff that Tor Browser will expose without it (including many details about the hardware).
In addition to that, we try to move to Firefox all the patches that could benefit also to (some) Firefox users. This will also reduce the chances the new developments will break our patches.
Often, when we upstream these patches, they get gated behind RFP.
So, as a matter of fact, disabling RFP is like removing some patches that in old versions of Tor Browser could not be disabled at all.
3 Likes
Thanks for the explanations @thorin and @PieroV
Wow, there are people who access a hidden menu, click through a big warning message, and then search for an obviously privacy-related setting to disable? That takes some dedication to sabotaging personal privacy. I hope those people aren’t “at risk” individuals and are only using the Tor browser for “casual” purposes!
But this does raise interesting questions. I’ve never changed the Tor browser theme myself, but have often wondered what the privacy implications of this would be. The default seems to be to follow the system theme instead of being set permanently to “dark” or “light”, therefore I assume that it shouldn’t make a big difference if it is set as one or the other. I would also think that if it is okay to resize your browser with letterboxing enabled, then using similar logic it also shouldn’t be a big problem if 50% of people ues a light theme and 50% of people use a dark theme? In previous versions of the Tor browser you could change the theme in the standard settings menu, but now that I look it seems this option has been removed from the standard settings menu in the latest version of the Tor browser.
It would also be nice if there was a comprehensive list somewhere of settings which can be changed without affecting privacy and which settings can’t be changed without affecting privacy. I can understand the frustration of users when the advice is “just don’t change anything” when there obviously are some settings which can be changed without affecting privacy, but there is little guidance about this.
That’s interesting. And those patches have no individual boolean settings to toggle them on or off, like a subsetting of RFP?
That’s another way to do it, but anyway I already tested with Tor alpha browser and it seems that the website actually is feature testing, as it still refuses to work even with an up to date user agent.
I’m not sure what you mean. I’m using up to date Tor browser, which as you know is based on Firefox ESR 115.
Any instance of Element using the latest version of the web app.
Element just says the browser is too old and doesn’t have the latest necessary features, but unfortunately it doesn’t say what those missing features actually are. In my experience Element’s error messages are unfortunately of limited usefulness and sometimes not even accurate, so you can’t rely on these error messages to tell you the real problem.
Yes 
.
Indeed thorin and me would like to make that warning scarier and show it every time you go to about:config (i.e., remove the checkbox to skip it, at least on release).
However, some users don’t care about privacy, and use Tor Browser only for censorship circumvention.
Browser’s theme is not a problem.
“website appaerance” would be relevant to fingerprinting (it changes the result of the prefers-color-scheme CSS media query).
However, RFP takes higher priority, so that UI element is ignored and we removed it to avoid the confusion.
You can still change the browser’s appearance in about:addons.
IIRC, downloading themes from addons.mozilla.org isn’t fingerprintable, but you should double check that (I must have written something about it in our Gitlab).
Regarding letterboxing, it’s a good measure, because it reduces the precision of the window size, so you’ll get grouped with other people who use similar sizes (either resolution or non-maximized windows).
However, the user population is spread across several buckets anyway (only one fingerprint for everybody isn’t a real thing, we can only try to minimize the variables/bucket number).
Sometimes they do, especially if it would be too much also for RFP.
For example, I submitted a patch to display only “Tor Browser”(/“Mozilla Firefox”) as window names, to avoid accidental disk leaks (e.g., in logs).
That would be too much even for RFP (and eventually also our UX team asked to defer this setting as the default to a future version).
The successor of RFP is called FPP, and offers more granular settings (e.g., you can decide to lie about your hardware, but not lie about your timezone).
So, when we upstream patches we usually have to specify a certain category of FPP.
However, we don’t plan of switching to FPP, because of various reasons (e.g., our population is already small enough that we don’t want to segment it too much/even more).
In this case it’s true, it’s Intl.Segmenter. We have a GitLab issue about it, which we closed because we currently backport only security fixes, I hope you can understand.
Element, on the other side, refuses to support Firefox ESR.
I think it’s very unfortunate that for too many web developers supporting only the browser releases of the last couple of months is okay.
On the plus side, 14.0, based on Firefox 128, should hopefully come at the end of September.
1 Like
Hmm I wonder if surveys and usability studies show Tor users have a preference for a light theme or dark theme? If the majority of users prefer the dark theme, maybe it is worth making the dark theme the default for everyone?
It’s good we have people like you thinking about these things, it’s not something many people would think about. But I can understand the perspective of the UX team on this one. Many people only include the network in their threat model, not the device and client software they are using, and for people who use a FOSS stack who are not “at risk” and not likely to have their device seized, it probably doesn’t make sense to include this in the threat model IMO.
That makes sense. (I assume FPP stands for “Fingerprinting protection”.)
About the timezone, I noticed a few months ago that the local timezone showed up in about:downloads (although websites still saw the masked timezone), but now it’s back to “normal” and about:downloads shows the masked timezone again. I guessed it was a weird bug and didn’t think too much about it.
Ok, thanks for pointing this out.
I agree. Element’s willingness to break things for stable users is very annoying.
Getting this kind of data is usually hard for us.
We don’t have telemetry, so we can only create surveys… which have their own set of problems.
So far we’ve kept light mode to match the default behavior of other browsers.
To be completely honest about it, we didn’t think about this specific case.
It happened “on the wild”: a user who was having problems with GNOME Shell found the window title in logs.
Yep. The idea is to include settings to enable/disable the protections that cannot be fingerprinted remotely.
The window title is a low hanging fruit (all the OS we target have an API to enumerate windows and get their titles; often they’re not used for mischievous purposes, still a leak isn’t pleasant).
However, we know we cannot do much against a hostile system.
An OS like Tails is one of the few solutions when you are in such a position.
The local timezone is expected in some parts of the browser: safe areas (such as the UI) are exempt from RFP/FFP.
In the code, you usually pass also the context where a certain lie would be shown.
If it’s the browser UI (which is implemented in a mixture of HTML + XUL, a legacy language Mozilla developed many years decades ago), this check will tell you not to lie, so you will see your local timezone.
^ they’re called principals