[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:
----------------------------------------------+--------------------------
Changes (by gk):

 * cc: mcs, brade (added)
 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam201811
 * status:  needs_information => new


Comment:

 Replying to [comment:2 sysrqb]:
 > I think it is intentional that the app profile extensions override the
 system addon: [https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/extensions/internal/XPIProvider.jsm#n2105
 in XPIProvider] - at least this is how I am reading it.

 That's actually okay I think. The bug here is that the there is an
 integral extension, which we don't ship anymore compared to the previous
 bundle, still available after the update and not deleted.

 For Linux/Windows we get that essentially for free as the profile is
 included inside of the bundle and the logic determining which items to
 remove/replace is running across the profiles on those platforms as well.

 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.

 > I wonder if we should do something slightly hacky. In the
 `PostUpdateHandler`, when the system extensions are copied into the
 `features/` dir, we check if the same addon is already installed in the
 profile, and we uninstall it if it is found.

 Sounds fine with me if we don't fine a better plan.

 > (I don't know how to initiate an uninstall of an addon from Java -
 [https://gitweb.torproject.org/tor-
 browser.git/tree/mobile/android/chrome/content/aboutAddons.js#n344 the
 javascript is context sensitive] - plus it requires another restart before
 it is it fully uninstalled, but that's another problem).

 Yeah, le't not go that route.

 > The third problem is preferences.json isn't copied from the apk into the
 app's data directory. I think this is because the the app
 [https://gitweb.torproject.org/tor-
 browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n520
 sets a preference] (`distribution_state`) when initialization completes,
 and then it [https://gitweb.torproject.org/tor-
 browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n491
 never copies new files] from newer APKs during an update.

 That's annoying. I think we should make exceptions for the files we care
 about. Or we could just put some logic in the `PostUpdateHandler` here as
 well.

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