[guardian-dev] Build process for Android Tor binary

Rod Hynes r.hynes at psiphon.ca
Thu Jan 16 11:36:46 EST 2014

On Tue, Jan 7, 2014 at 12:00 PM, Michael Rogers wrote:
>> One last thing on this... make sure to change the default ports in
>> the torrc file you bundle, so that you can run Briar and Orbot on
>> the same device without conflicts.
> Yup, we're using different ports. I plan to test Orbot and Briar
> side-by-side to make sure there are no conflicts.

Hi all,

We're working on a project called Ploggy
(https://github.com/Psiphon-Labs/ploggy) which, like Briar, includes
an Android app that bundles Tor (Orbot's build) and uses Hidden
Services for a P2P social network. We considered the same pros and
cons of using Orbot vs. bundling our own Tor and are currently
bundling/running our own instance for many of the same reasons Michael
listed. One further reason in favor of using Orbot that was not
mentioned is that the user will have to manually configure bridges for
each app that runs its own Tor.

Ploggy's Tor wrapper [1] is based on Briar project's Tor plugin. We're
using the Tor config options "ControlPort auto" and "SocksPort 0" to
allow our Tor instance to pick whichever free ports are available for
the control port and SOCKS port. This maximizes the chance that our
app will run, and probably makes conflicts with Orbot very unlikely,
although it's not guaranteed.

In testing Ploggy and Orbot, we found that Orbot (12.x and the new
13.x release) fails to run once Ploggy is already running. The reverse
order isn't a problem.

As best as we can determine, this happens when
TorService.findExistingProc [2] uses pidof with the name "tor" [3] and
finds Ploggy's "tor" process -- which it can't connect to because the
control port isn't 9051 (also, Orbot won't have our control auth
cookie). Note: this problem appears to happen only in Orbot's root
mode. To fix this we now name our process "ploggy-tor".

On Sat, Jan 4, 2014 at 12:00 PM, Hans of Guardian wrote:
> 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.

We've been running Ploggy, as a P2P location, message, and photo
sharing app, within our development team and with a few associates for
some time and would be happy to discuss our informal experiences so
far. In brief, our first impression is that we're surprised at how
well Tor hidden services perform for our application (currently Ploggy
is a resource hog though -- wastes a lot of data and battery, which
may be due to Ploggy -- there are known gross inefficiencies in our
code -- and/or running a Tor instance).

>From time to time we see problems with Tor; such as getting stuck at
5% bootstrap. Typically it takes under a minute for Tor to reestablish
a circuit after, for example, coming out of the subway (no signal) or
going from WiFi to mobile data; and to publish a Hidden Service. So
far, this seems decent enough performance for Ploggy, which is
intended to offer an asynchronous messaging experience.


[1] https://github.com/Psiphon-Labs/ploggy/blob/master/AndroidApp/src/ca/psiphon/ploggy/TorWrapper.java
[2] https://gitweb.torproject.org/orbot.git/blob/c3327d7ae8e3681f0aac3bba682861a4560ce78e:/src/org/torproject/android/service/TorService.java#l133
[3] https://gitweb.torproject.org/orbot.git/blob/c3327d7ae8e3681f0aac3bba682861a4560ce78e:/src/org/torproject/android/service/TorServiceUtils.java#l47

More information about the Guardian-dev mailing list