[guardian-dev] Build process for Android Tor binary

Hans-Christoph Steiner hans at guardianproject.info
Fri Jan 3 17:47:24 EST 2014

On 01/03/2014 05:07 PM, Michael Rogers wrote:
> 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.

These are both goals that we share with our apps that use Orbot.  For
out-of-band sharing, check out our work with adding p2p sharing to F-Droid as
part of the Bazaar project.  I think we can help the situation there a lot by
adding support for dependencies, so then ChatSecure/Briar/etc. could depend on
Orbot like in Debian/Fedora/etc. and installing the app would also install
Orbot if needed.

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

Our experience is that hidden services perform quite poorly with frequent
changes.  We'll be quite interested to see if you can improve that situation
measureably, we've figured its not really usable for messaging as it is.

Another thing you'd have to duplicate in your new tor implementation is
linking up Tor with the Android lifecycle and also handling the wifi/cellular
sleep states, as well as transitions between wifi and 3G, or sleeping tor on
loss of internet.  Just running the tor daemon leaves out significant parts of
the Android integration.


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

PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 969 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140103/f7b8c85f/attachment.pgp>

More information about the Guardian-dev mailing list