[tor-bugs] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
----------------------------------------------+--------------------------
 Reporter:  sysrqb                            |          Owner:  tbb-team
     Type:  defect                            |         Status:  new
 Priority:  Very High                         |      Milestone:
Component:  Applications/Tor Browser          |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811  |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+--------------------------

Comment (by mcs):

 Replying to [comment:4 gk]:
 > For macOS the case is different as we needed to get the profile outside
 of the bundle directory for code signing purposes (see: #13252, and note
 that we plan to do so for Linux and Windows, too, as there are a bunch of
 bugs with our current way of doing things on those platforms, see: #18367
 and #18369). We solved that problem but I currently can't find the
 details, mcs/brade might know. That in turn might help to find a good
 solution for Android case and/or might help thinking through whether
 desktop platforms would be affected the same once we transition to a
 built-in Torbutton for them, too.

 On macOS, when we transitioned from "profile embedded within the app" to
 the "side-by-side" TorBrowser-Data approach, the normal update mechanism
 took care of removing all of the extensions from the embedded browser
 profile. Here is the current #13252 patch for reference:
 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-60.3.0esr-8.5-1&id=86e3b0eabbd3b1f02d755399074e511eb5784aa2

 The patch does include some migration code which moves the browser profile
 over to TorBrowser-Data, but I don't think that code needs to do anything
 special for the extensions (since they will be removed when the MAR-based
 update has been applied, and that occurs before the profile migration code
 runs). If you want to see the migration code, start by looking at
 `migrateOneTorBrowserDataDir()` inside `toolkit/xre/nsAppRunner.cpp`.

 We also added some code to help with preferences overrides. From the
 commit message:
  All .js files in distribution/preferences (on Mac OS,
 Contents/Resources/distribution/preferences) will be copied to the
 preferences directory within the user's browser profile when the profile
 is created and each time Tor Browser is updated.
 I don't think we rely on that code any longer due to changes made for
 Firefox ESR 60, but you can see the relevant code by looking at the
 changes to `toolkit/mozapps/extensions/internal/XPIProvider.jsm` as part
 of the #13252 patch.

 One crazy idea that might work as a quick-and-dirty solution would be to
 blocklist the old Torbutton. Using that approach would require using a new
 extension ID for the system add-on... which is inconvenient. I am sure we
 will encounter this same issue for desktop (at least on macOS), and we
 will probably need to add code to
 `toolkit/mozapps/extensions/internal/XPIProvider.jsm` that removes all
 traces of the old profile-based extension.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28640#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online