[tbb-bugs] #27466 [Applications/Tor Browser]: Investigate single-locale language repacks for Tor Browser on desktop

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Feb 8 19:14:33 UTC 2019

#27466: Investigate single-locale language repacks for Tor Browser on desktop
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:  new
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  GeorgKoppen201902,                   |  Actual Points:
  TorBrowserTeam201902, AffectsTails             |
Parent ID:  #28196                               |         Points:
 Reviewer:                                       |        Sponsor:

Comment (by gk):

 Replying to [comment:18 intrigeri]:
 > I've taken a look again after trying to find a good solution for Tails
 if/when Tor Browser drops the langpacks entirely ''and'' does not start
 providing a multilingual tarball. I think there's a workaround that should
 hopefully work for Tails but it's ugly (basically: download the langpacks
 from Mozilla ourselves, patch them ourselves to apply Tor Browser's search
 plugins and bookmarks customization, and turn
 `extensions.langpacks.signatures.required` off ourselves; i.e. essentially
 do on our side what `projects/firefox-langpacks/config` and `projects/tor-
 browser/build` currently do when building Tor Browser); for somewhat silly
 reasons you're probably not particularly interested in, it also requires
 repetitive busywork for us. Let's say that's… not my idea of "fun".
 > So I've taken a look at the related bugs (#26465, #18915, #21879,
 #11236) and some of the linked Mozilla bugs to try to understand what's
 the big deal here. My understanding is that we want to do this because:
 > * It would be nice to make the tarball and upgrade deltas other than en-
 US smaller, because they would not include en-US strings anymore. Each
 langpack is currently 500-600KB large and each localized tarball is 72MB
 large, so the single-locale repacking technique could potentially save up
 to 0.8% on the size of a tarball. I suspect there are lower-hanging
 fruits, with a better cost/benefit, if we want to shrink the bundles (but
 I would be happy to stand corrected if you tell me that all those have
 been fixed already so that <1% optimizations are now a sensible goal :).
 > * Mozilla does not support overriding bookmarks and search plugins in
 any suitable way.
 >  * So we currently have to patch every langpack.
 >  * It follows that we need to turn
 `extensions.langpacks.signatures.required` off.
 >  * But that's not nice and we would prefer to enable
 >  * So the only way to fix that is to get rid of the langpacks entirely,
 with this single-locale repack technique.
 > * Ship something closer to what Mozilla is shipping (I'm assuming
 they're applying this technique to their own localized Firefox desktop
 downloadable products). Note that this is only relevant for Windows and
 macOS: AFAIK most Linux users get Firefox from their distros and I doubt
 distro packages use this technique; at least on Debian, one gets an en-US
 Firefox and installs the langpack via the `firefox-l10n-$LOCALE` package.
 So I'm quite confident that Mozilla will keep supporting "en-US +
 langpack" for the foreseeable future.
 > * Any other reason?

 This list is good, thanks for that. Yes, there is another benefit: we
 could get our security bugfixes out earlier as we don't need to wait on
 the langpacks being ready to start the build. We are talking here about a
 couple of hours which seems like a good win in case of emergency releases.

 > Zooming into the reason that seems the most valid to me, I guess we want
 to enable `extensions.langpacks.signatures.required` because:
 > * Firefox may simply stop supporting this pref some day and then we
 might have to deal with this with only a few months notice.
 > * For defense in depth reasons: if the Firefox add-on updating code is
 buggy or AMO is compromised, and our code that disables updating most add-
 ons is buggy, then presumably an attacker could force an update to a
 langpack they control, and then all kinds of undesirable things can
 > If this analysis of our motivations is about right,

 Yeah, I think that's the case.

 > then I would argue that sure, it would be very nice to have, but perhaps
 not urgent to the point of rushing this just a few weeks before 8.5. If
 it's an option to relax the timeline a bit, then we can perhaps do some
 > * Revisit some of the other options you've mentioned in
 https://trac.torproject.org/projects/tor/ticket/18915#comment:3 for search
 > * Check if Mozilla would be open to adding a pref that disables looking
 in langpacks for bookmarks and search engines. Then we don't need to patch
 them, we can enable `extensions.langpacks.signatures.required`, and the
 main reason to do what this ticket is about is gone.
 > * Block this on having one-bundle-including-all-locale for desktop
 > Now, if there's a cheap, possibly dirty but good enough workaround that
 Tails can apply in time for 8.5, I'll happily let you handle this in this
 timeframe and I'll shut up :)

 No need to shut up. That's been a good summary and analysis. Now, alas, I
 won't have time to work on that for 8.5 as I need to help out to get the
 browser for Android into a shippable state. Thus, this won't come before
 9.0. And, yes, this ticket is about an investigation, so we might at the
 end find we achieve our goals better by other means (but I am skeptical so
 far). Right now the most important one is getting the signature pref
 enabled, followed by starting builds earlier, followed by being closer to
 what Mozilla ships, followed by saving several hundred kBytes (Note,
 though, it will actually be quite a bit more we could save, given that we
 would not need to ship all Torbutton locales and Tor Launcher locales
 either anymore which is tracked in #5184).

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

More information about the tbb-bugs mailing list