[Tails-dev] Shipping the Tor Browser? [Was: minutes of a tai…

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: The Tails public development discussion list
CC: freepto
Assumptes vells: [Tails-dev] minutes of a tails/freepto meeting
Assumptes nous: Re: [Tails-dev] Shipping the Tor Browser? [Was: minutes of a tails/freepto meeting]
Assumpte: [Tails-dev] Shipping the Tor Browser? [Was: minutes of a tails/freepto meeting]
Hi,

[I'm unsure if I should Cc Freepto here. Possibly some of the concerns
described below also affect them. But most is Tails-specific.
@Freepto: just tell us if we should drop you from the Cc list on
that one.]

boyska wrote (29 Jun 2014 22:07:23 GMT) :
> TorBrowser: TBB and TBL
> =======================


> We discussed the benefits and cons of having a "launcher" (TBL) instead
> of the whole TBB inside the image. Of course putting it inside will
> ensure shorter 'opening' times; this is especially true for live
> systems.


> We ended up saying that having the TBL pre-downloading
> the TBB during image building (with a chroot-hook) would be the best
> solution. Boyska volounteered on that: this would require something like
> torbrowser-launcher --batch-download


While we were having this discussion, it occurred to me that some of
our reasons to build our browser ourselves might not be valid anymore:
back when we decided to go the iceweasel + TBB patches way, in October
2012 ("Tails 0.14 vs. iceweasel 10.0.9esr-1" thread), our belief that
"TBB in Debian" would become real was the strongest argument in favour
of doing what we finally did. There's been no recent progress on the
that front recently, and I doubt anything will happen any time soon.

So, it might be than shipping the Tor Browser could be our best option
nowadays, especially with a) the fancy hardening options that are
being added to it (4.x branch), that we can not have before
Tails/Jessie with our current setup (#7155); b) the potential to share
more code and work with Freepto and Whonix.

Still, I see a few stumbling blocks:

1. There's no TBB tarball with all locales; back in the days, Ague had
written a script (install-tbb.sh) that got the locales from the
Debian package; I was concerned with the potential for
incompatibilies with the TBB binary, but presumably, downloading
all TBB tarballs and merging locales is doable; best would probably
be to have the TBB build scripts *also* build a tarball with all
locales in. Then, maybe we can use torbrowser-launcher --batch-download.

2. At the time we want to build our ISO, the TBB hasn't been
officially released yet. We could take the tarball(s) that are
under QA, *but* then torbrowser-launcher doesn't know how to get
these, and at least once I've seen these tarballs lacking OpenPGP
signatures. Possibly building the TBB ourselves from the Git tag,
instead of downloading it, would be the best; it would add one
verification data point to TB's deterministic build process, which
surely would be appreciated by the TBB folks. But then, if Freepto
wants to use torbrowser-launcher instead, the additional amount of
stuff we're sharing with them is not substantially increasing.
Another option would be to add another command-line switch to
torbrowser-launcher, to have it download unreleased tarballs that
are under QA.

3. Related to #2: it might be that the TBB signed tag is published
a bit too late in our release schedule. I've not checked. Also,
sometimes they do a -build2, -build3, etc. to fix issues discovered
by QA. But anyway, with the way we currently do it, we're missing
the late changes brought by these updates too, so it probably
doesn't matter that much.

4. TBB will soon use its own updater. Either we want to disable it,
and rely on our existing update mechanisms; or, we want to use it.
In the later case, as boyska rightly noted, there's room for
incompatibility with the desire to confine the browser in
a sandbox: it seems obvious that one of the first tasks such
a sandbox should fulfil would be... to avoid the program under
attack from modifying itself. I'll take this discussion to the
tbb-dev list.

5. Migrating away from our current setup needs quite some initial
work. I'm especially fearful of the way we deal with Firefox
preferences, extensions, and patching thereof in camouflage mode.
Arguably, this will be quickly compensated by the reduced amount of
repeated release management work. With this in mind, this could be
a relevant goal for the 2.0 milestone.

6. If we ship the TBB, what do we do for the Unsafe Browser? Use the
same binary? Instead ship a dedicated unsafe browser, such as GNOME
Web (Epiphany)?

Right now, I'm unsure if we should go this way, and I doubt it should
be prioritized above the 2.0 tasks some of us are already committed to
take care of for the rest of 2014. Still, if we could discuss it and
make a decision, then perhaps other people could take care of it :)

Thoughts? Other pros and cons?

Cheers,
--
intrigeri