Skip to content

Make Tor Browser easier to fork and uplift

We would like to make Tor Browser easier to uplift and fork.

Ideally, Tor Browser should start from the "Rebrand Firefox to TorBrowser" commit, and whatever come earlier should be either uplifted to Firefox, or could be part of any Firefox fork that enhances privacy and security.

We should also take this occasion to do some maintenance to Tor Browser itself.

First pass

On the first pass, we want to obtain a second rebase of Tor Browser 11.5a/91.9.0esr like the previous one, but we should move any commits that makes sense to, and make upliftable patches (almost) ready to be sent to Mozilla.

Prepare the MR

  • Handle common and not common preferences
    • Move the remaining Tor-only preferences from ca7f4806 to 61f4f38c
    • Rename the 000-tor-preferences.js to a common preference file in ca7f4806, and then include it in 61f4f38c
  • Review preferences, and remove the deprecated ones (#40783 (closed), #40656, etc...)
    • Remove the one for #13579 (closed), as it is not needed anymore (#40916 (closed))
    • Change svg.in-content.enabled to svg.disabled (which is then managed by security level)
  • Drop 6f66099e because the included Firefox protection works better
    • Firefox's mitigation is enabled by default, but we disabled in the commit we're dropping to use ours. So, after dropping the commit, we don't need to do anything to make sure that the protection is enabled again.
  • Drop 16344ab0, because now getComputedStyle returns normal for line-height (#40919 (closed))
  • Remove "Tor Browser" references from patches before the rebrand commit
    • 90f81703
    • b047896e
    • 275dfe97
    • 20bf273c
    • c09d40ef
    • 663aded1
    • b7b5befa
    • 60eb7990 - this embeds the relative profile directory, so not only the Tor Browser name in comments. We should think about specifying it in a configuration option, e.g. --relative-profile-path, and enable the feature whenever the flag is set (and be uplift-friendly)
    • 4ff0d620 - remove any TOR_BROWSER_DATA_OUTSIDE_APP_DIR from the previous patch, and add them back in this one, but move it after the branding part, and use some other macro(s) (i.e., make this the only option for Tor Browser on macOS) this has become a Tor-only patch
  • Uplift-related
    • Investigate the following commits:
      • 60eb7990 (i.e., relative profile directory/profile directory relative to the installation directory; it would be useful also for a portable mode)
        • 4ff0d620 does this complete the previous one?
      • 275dfe97:
        • consider dropping it (#31075)
        • if not, improve if needed, add a preference and then uplift?
      • 68a0dfde: added a check to enable it only in resist fingerprinting (6fe63d43)
    • Add preferences/command line options to make commits more likely to be uplifted:
      • 663aded1: add an #ifndef MOZ_PROXY_BYPASS_PROTECTION, rather than just deleting the existing code
        • The rationale behind this was that the main reason to disable system policies in first place was that a system proxy prevails on our proxy settings
      • b7b5befa: add its own configure flag (--disable-system-policies), rather than depending on --enable-proxy-bypass-protection
    • 663aded1: reword, as the original patch has changed
    • b047896e: use MOZ_PROXY_BYPASS_PROTECTION and remove the printfs.
  • Investigate 7d249f76
    • It's blocked because of Bugzilla#1261591 - ask for permission to enter it
    • Mozilla won't fix it and who could fix it won't as well. Chromium-based browsers are affected as well. Recommended solution: update the commit description to include the link also to the second issue, and move it after e522dbea (so, make it the first commit for the DESK-DISABLE category).
  • Do something like preferences for mozconfigs (tor-browser-build#40477 (closed), tor-browser-build#23656 (closed))

Before merging

Ideally, these should be done by the reviewer, rather than the MR author.

After merging has been merged

Tests

For changes in code, we should make sure they did not affect any feature.

New command line arguments/preferences

For added preferences/command line arguments, we must make sure to add them in the preference file/mozconfig files.

  • --disable-system-policies
    • on 40d50526
      • add a reference to the bugs: (#30575 (closed), #32418 (closed): We want to allow user policies because they allow to specify some options that cannot be set through preferences, such as disabling updates. However, we need to disable the system ones, because they may override our proxy, and possibly add other unwanted options)
    • on tor-browser-build (with comments)
  • ac_add_options --with-relative-profile=TorBrowser/Data/Browser (Linux&Windows)
    • on tor-browser.git
    • on tor-browser-build.git

Close issues to inform users

Some of the changes we do in this process close existing issues.

This is very good, because we can add them to the changelogs, and interested users can test if we break anything.

Therefore, in some cases, if an issue does not exist, we should create one, just to track what we are doing further.

Second step

In the second step, we should integrate tor-launcher and torbutton in tor-browser.git, rather than keeping all these separate repositories.

Commits to move before the Tor Browser branding

These commits have been moved after the branding step only because they need localized strings, which are managed through the other repositories.

Uplifts

Please add the Bugzilla link, once available.

Edited by Pier Angelo Vendrame