#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 sysrqb): Replying to [comment:5 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. Thanks! Part of the problem we're having on Android is the update mechanism is completely different than on desktop - so we don't benefit from the same MAR logic. I do think, and I agree, the torbutton transition should affect Mac OS the say way it affects Android, though. > > 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. Interesting idea, and I don't think it's too crazy. One other idea I have is we can conditionally ignore a `torbut...@torproject.org` xpi during startup if it's not a system addon: https://gitweb.torproject.org/tor- browser.git/tree/toolkit/mozapps/extensions/internal/XPIProvider.jsm?h =tor-browser-60.3.0esr-8.5-1#n1600 -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28640#comment:6> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs