[tor-dev] Sandboxed Tor Browser should be officially developed

Yawning Angel yawning at schwanenlied.me
Sun Jun 17 14:08:02 UTC 2018

[Well, I already got my first bit of automated spam from the last post,
 so I might as well reply again.]

On Sat, 16 Jun 2018 20:34:03 -0700
Chelsea Holland Komlo <me at chelseakomlo.com> wrote: 
> As you pointed out, this project is no longer being actively
> maintained. While someone on the Tor Browser development team can
> answer more thoroughly, my understanding is that the original
> maintainer moved on from working on this project. The Tor development
> teams are quite small, so (like many open source projects) there are
> more projects than people to support them.

Essentially, yes.

TLDR: I do not have the resources to dedicate to maintaining this, and
in the long term the project should be replaced by a correctly
re-designed Tor Browser that can sandbox itself anyway.

In a more concrete terms, the "correct" thing to do would be for a
non-trivial amount of work to be put into making Tor Browser support
better isolation and sandboxing on it's own, rather than someone be
stuck with trying to retrofit it to do things that the current design
and architecture are ill suited to doing.

Till something like that happens, a large amount of time, effort and
code will be spent on replicating existing functionality such as the
launcher, updater and configuration interface.

This requires extensive changes to the existing Tor Browser design.  As
an example of what would be required,  M. Finkel's design proposal[0]
describes the steps required to change the Tor Browser architecture to
something that is less nightmarish to sandbox, and provides better
component isolation.  As far as I am aware, there is no one working on
that either.

There are other fundamental unresolved questions specific to Linux
sandboxing (eg: X11, D-Bus) that need to be resolved in a user-friendly
manner (eg: blocking all of D-Bus a la `sandboxed-tor-browser` is
unacceptable for mass adoption), but the better isolation brought on by
the architectural change on it's own would be an improvement over a
vanilla Tor Browser install, and it would let whoever is working on
such things, focus on such things, rather than being forced to
re-implement large parts of Tor Browser.


Yawning Angel

[0]: https://lists.torproject.org/pipermail/tbb-dev/2018-January/000743.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180617/a988f2d0/attachment.sig>

More information about the tor-dev mailing list