[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-
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
> * 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