[guardian-dev] Build process for Android Tor binary

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First of all I want to say that I'm really grateful to the Guardian
project for getting Tor working on Android and making the build
process so painless. Thank you Hans, Nathan, and anyone else who works
on Orbot!

On 02/01/14 18:02, Hans of Guardian wrote:
> This is a classic case where everyone will be better off if we
> pool resources.    Let me outline that.

Of course I agree that in general we should pool our resources, but
I'm not sure how that applies in this case. If I reuse the Tor binary
from Orbot but not the rest of Orbot, what's not being pooled that
should be pooled?

> The only ease-of-use advantage that including Tor in Briar has
> over an external Tor app is only installing one APK rather than
> two.  That is a real issue, but it is something that only happens
> once, and can be greatly streamlined.

It's really important for the installation and first run of the app to
be as smooth as possible. I don't want to add any unnecessary
obstacles - not even small ones.

Also, I mentioned before that we're trying to enable users to share
the app out-of-band. Splitting the app into two APKs would complicate
that.

> Other than that, the Android model allows for transparent
> interaction built up from multiple apps.  Orbot should handle this
> better, and we are planning out improvements to Orbot transparent
> integration now.

Interaction between apps is great, especially if there are multiple
apps that can handle a given intent (so the user can choose which one
to use), or if the interacting apps are built-in (so the intent is
sure to be handled). It's not so great if the user has to install
multiple apps to perform a single task.

- From the user's point of view, managing a Tor hidden service isn't a
separate task from using Briar. It isn't even a task, because the user
shouldn't need to know it's happening. So I don't think it's a good
fit for the idea of interacting apps.

> There are distinct ease-of-use disadvantages to including Tor 
> directly in apps.  That entire app must be updated if Tor needs to
> be updated.  That adds extra maintenance work for the Briar
> Project developers.

True, we'll need to recompile the Tor binary for each release. On the
other hand, we won't need to worry about the user having an older (or
newer) version of Orbot.

> Also, if multiple apps follow this model, then there will multiple
> tor daemons running, each with their own idle bandwidth usage,
> which can be hundreds of megs a month for each tor daemon. That's
> real bandwidth when talking about GSM/CDMA connections in most of
> the world.

It's funny you should mention that, because I see bandwidth management
as an advantage of our approach. If the user doesn't want to use
mobile data, we can disable Tor and other IP-based plugins whenever
there's no wifi. We couldn't do that if we shared a Tor process with
other apps.

In general, I'm skeptical about whether a single Tor process can serve
the needs of all Tor-enabled apps. Sure, it makes sense for a browser
and an email client to share a Tor process, because they use Tor in
similar ways. But a P2P messaging app that runs a hidden service will
probably want to configure the Tor process differently. So I think
there may be cases where sharing a process makes sense, and cases
where it doesn't.

> Adding things like support for changing the config file in a more 
> flexible way are definitely interesting for Orbot as well.  I
> think that you'll find that the usability issues in Orbot are not
> design issues, but rather resource issues.  We want to improve
> Orbot, but there are only so many hours in the day.  If more
> projects pool their resources behind solid, transparent, shared tor
> support, there will be more work on to make Orbot what we all need
> it to be.

Don't get me wrong, I think Orbot is a great piece of software. When I
talk about ease of use, I don't mean that Orbot has a bad user
interface. But I want Briar's Tor plugin to have no user interface at all.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJSxzSFAAoJEBEET9GfxSfM5/oIAMDB3heiqIG2gPwVXayfS+0f
RMFeeg2vnnCMKV5qxwjPeAUTfMdxzeGh31Y7V7B4DvDNLSsV4d5Oiv7W6Ywg47EY
gQdf2VdOz8bEEWzOmo9LVnEwdXeqkEqFsE1IqBV8C7AWxhfoaltBUfoe0wHgM50Q
QYoUgyh5qEafbIYPs6TuZtfUpLMARFMw5PcHCjEcFyJl2btJ/CJjV3ngC7DvG3B6
CTBUsAiYzEF25aJKSAT0j4YJwJHet7yE2+QfK1ZalZvc8LXSebja7OiJmxzrgykN
fMkpE6ABcT9M48k8xxe9QfLnwUOiCZ1zVsYwLAFHhzNcURdHBn1vCHiDmVRy6Vc=
=7TwE
-----END PGP SIGNATURE-----