[guardian-dev] Build process for Android Tor binary

Hans of Guardian hans at guardianproject.info
Thu Jan 2 13:02:25 EST 2014

On Jan 2, 2014, at 11:54 AM, Michael Rogers wrote:

> Hash: SHA1
> On 02/01/14 16:27, Hans of Guardian wrote:
>>> Why do you want to include the tor binary in Briar?  Why not just
>>> rely on Orbot to provide it for Briar?
> Hi Hans,
> There are a few reasons. First, ease of use: the Tor transport should
> just work, without users needing to download any other apps or even
> know what Tor is. Using a separate app to manage the Tor connection
> doesn't achieve that in my view.
> Second, we're experimenting with ways of sharing the app directly
> between users, so that people can get a copy without internet access.
> Using multiple APKs would make that harder.
> Third, jtorctl gives us more control over Tor's behaviour than
> OrbotHelper - for example, we plan to use 'stealth' hidden services,
> which requires writing authorisation data to the config file.
> Cheers,
> Michael

This is a classic case where everyone will be better off if we pool resources.    Let me outline that.  

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.  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.

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.  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.

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.


More information about the Guardian-dev mailing list