[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] To Toggle, or not to Toggle: The End of Torbutton
Being relying myself on Firefox profiles / virtual machines rather
than the toggle thing, I'd personally be happy to see it go away.
Let me put my Tails developer hat on. Done. Let's go.
Mike Perry wrote (11 Apr 2011 23:33:08 GMT) :
> The reason I am discussing this in so much detail here is because I
> believe there is a chance that there are users out there who rely on
> the toggle model and/or their OS Firefox build, and may be confused
> or enraged by the new model. I'm asking this list to get an idea of
> how many of those users there are, and to try to understand what the
> overall costs of this sort of migration are.
> So can anyone bring up any specific issues that may be caused by the
Context: Tails currently ships Debian's Iceweasel (Firefox renamed for
trademark reasons) and Torbutton. We don't care for the toggle feature
that is unsupported in Tails and generally confusing for Tails users.
Debian has put great efforts  to avoid shipping embedded code
copies, and I quite like it from a sysadmin point-of-view, but this is
mostly irrelevant to the current discussion *in the context of Tails*,
so I'll try to put aside my usual rants: if there's a serious security
bug in, say, the FreeType library, we need to release updated Tails
images regardless of the actual technical reason (in case we go on
shipping Debian's Iceweasel with no embedded code copies + Torbutton,
we want to get the updated FreeType Debian package; in case we ship
the TBB, we want to get the new binary statically linked against its
own FreeType copy... I guess).
This being said... I fear needing to move away from a now-unsupported
Torbutton extension makes our life hard as Tails developers. Two main
issues arise from the top of my head, which I'm going to describe.
Since the end of Torbutton seems inevitable, I do hope my concerns can
easily be dismissed and the new TBB can be a viable solution for our
| Tails-specific Firefox profile configuration
For various reasons, the Tails Firefox configuration is likely to keep
being a bit different from the TBB's one. If we are forced to use the
TBB instead of our current Debian's Iceweasel+Torbutton, I wonder
how/if we will we be able to maintain this delta. I guess anyone needs
to know a bit how we currently do this, so as to be able to answer
this question of mine. Let me explain a bit.
We Tails developers have invested quite a lot of work to avoid
maintaining in VCS / shipping files into $HOME that are of the binary
kind (be them really binary, or enough of a mess to make the diff
corresponding to a given change hard to understand). Since the good
old amnesia 0.5 days, we've been building such files programmatically
from plaintext, understandable source files at image build time.
Just like GConf settings, the Tails Firefox profile directory falls
into this category: it's pretty hard to track such a directory in VCS,
change options in there while maintaining consistency, know what files
shall be shipped, which ones are auto-generated at runtime and so on,
among the huge pile of files one can find in a profile directory. To
achieve this we use:
* a system-wide profile skeleton  that mostly contains the
preferences *.js files and two extensions that have not made their
way into Debian yet
* SQLite preferences files are generated at build time  from
plaintext SQL sources 
If we migrate to shipping TBB, can we go on maintaining our Tails
specific Firefox configuration delta as described above? Will the
TBB's Firefox use the standard ways to fetch system-wide
configuration? (I guess this should be a opt-in option, probably not
toggle-able from the GUI, as the TBB usually wants to be as much
independent from the host OS as possible.)
| Compatibility with FF extensions installed from Debian packages
For maintainability reasons, we Tails developers tend to prefer
automatic build/upgrade procedures over manually setting up things. We
also tend to prefer benefiting from already existing infrastructure
and processes that work well, and especially Debian's ones, over
setting up our own ones.
For such reasons, I feel it's both cleaner and much less
time-consuming for us to install and ship Firefox extensions from the
Debian archive than manually downloading those, checking file
integrity and unzipping XPI files into the profile skeleton directory.
Maintaining compatibility between various FF versions and various
extensions is also work I would not want to do... especially since
it's already being done by the Debian maintainers for the extensions
we ship. I'd hate having to replicate their work.
Is it imaginable to see the new TBB make use of extensions that are
installed system-wide? (probably opt-in as well)
> We are collecting these issues as child tickets of this bug:
I'll summarize the discussion results there. In the meantime, I prefer
using email if you don't mind.
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| We're dreaming of something else.
| Something more clandestine, something happier.
tor-talk mailing list