@thermosflask So the UI question is a good one and the current reality of Tor Browser having a number of options in about:preferences which aren’t officially supported is basically due to years of conflicting constraints and limitation on capacity.
In general, we tend to be fairly slow to modify the built-in about:preferences UI in Firefox. This is out of a few conflicting realities:
- We want Tor Browser to be as private and secure as a browser can possibly be
- We don’t have any telemetry in Tor Browser, so we don’t have an easy way to know which of these feature are being used by our users
- We don’t want to force changes onto users which break their workflows, unless it’s for a solid privacy or security reason.
- We have historically had quite limited UX and developer capacity
- Mozilla’s UX and developer capacity is massive compared to Tor Project’s
All of this combined leads to the reality of a lot of functionality in the browser that exists which (if we were starting from scratch) we would not want.
Mozilla generally churns out changes faster than we can evaluate and audit them. Every summer we evaluate a year’s worth of Mozilla changes and prioritise auditing and modifying or disabling changes which may affect our users. Some of the resolutions are quite obvious (e.g. disabling telemetry) while others less so (e.g. in-browser web-content translation). And, every summer we inevitably end up with some set of Mozilla features or changes we aren’t sure about, so we disable to audit later (search in our gitlab for ‘audit’, we’ve a big backlog). One annoyance that we often run into and have to work around or somehow deal with is browser features which improve accessibility or general usability which necessarily reduce the privacy of the browser when enabled.
Over the past several years, we have been prioritising making the ‘Tor’ part of Tor Browser easier to use and seem like a pleasant, cohesive experience. It was not so long ago that Tor Browser was a somewhat difficult to use, cobbled-together collection of xul extensions. And that’s not shade on past development efforts, we were starting from nothing and that approach was the easiest way to add Tor functionality to Firefox. But time has progressed, our tech has improved and we have invested a lot in both usability and developer sustainability. Nearly all of the special sauce which makes Tor Browser as good as it is now is part of our fork of Firefox itself (i.e. torbutton, tor-launcher, https-everywhere, etc). The only exception here is NoScript. Of course, as we add and improve new Tor Browser-specific features (e.g. tor integration, fingerprinting protections, censorship-circumvention, etc), it takes more effort to migrate between the major Firefox ESR’s since there is more Tor Browser-specific code to update and test.
Historically, we have never consistently had more than two UX designers available for the entire Tor Project organisation (i.e. for all Tor Project products+websites, not just Tor Browser and Tor Browser for Android). So, even if we had developer capacity to implement all of the required changes, we also have a bottleneck on the amount of UX feedback and designs we realistically have available to us to implement in a release cycle.
All of this combined basically leads us to the situation we have now where prefs which are borderline, or which informed users may have a reason to use get left in about:preferences. Basically they aren’t judged to be important enough to spend effort on in comparison to all of the other work which definitely does matter, so they are ignored or an issue is created in gitlab to ‘fix this when we have time’.
