A happy note on Tor support

Jun 7, 2014 at 12:57 AM

Thanks to the example provided by Netcipher/Guardian Project I was able to successfully route requests via Tor to a TDH behind a Tor hidden service from both Java and Android!!!!!!! I know... I know.... lots of people have done this before but it still feels good to add us to the list. :) I especially like that we have a single code base that will run easily in both Java and Android that handles this. I had to modify the Netcipher code in trivial (thankfully) ways to make this work since Netcipher uses a 're namespaced' version of the Apache libraries rather than the HttpClient built into Android.

Note, btw, that Netcipher is quite smart to NOT use the Apache libraries in Android since they are very old. See https://thali.codeplex.com/workitem/62 for the gory details but we are going to have to eventually do something similar. But not today.

Now I need to go set up our plan for how to support running the Tor Onion Proxy (OP) in both the desktop and in Android.

For desktop this is pretty straight forward. You run the Tor executable with a torrc config file and it's good. My assumption is that ONLY the TDH will run the OP, not apps. I am further going to assume for the moment that there will be one TDH per machine so we can run things on hard coded ports. And yes that's wrong and yes we will eventually have to fix it and no, not today.

On Android things are a tiny bit trickier. We can run Orbot which is really just an Android wrapper about the Tor executable. It will let us do what we want to do but at a price. We have to use their client library in our code in order to detect if their stand alone APK (e.g. a separate Android executable) is installed and if not prompt the user to install it. Then we use intents to start a hidden service, which will cause Orbot to prompt the user to approve and then we get the hidden service address. This is all reasonably straight forward though and has the benefit that if there are updates to Orbot we get them automatically.

My expectation is that at some point Orbot will factor itself out into an AAR (Android Library) so we can take a direct dependency. This gives us better control over what version we are running against and avoids the extra UX and download issues. Briar has actually already pulled out the core code from Orbot and runs it embedded today.

My main issue is that if we go the 'vanilla' Orbot route then everything from testing to user experience is going to kinda suck. I suspect there are UX based tricks we can use during testing to auto-click on Orbot's dialogs but man I don't want to get into that mess.

So I'm probably going to take a hard look at the Orbot code and try to decide just how painful it would be to pull it out and put it in our code base. We shall see.


Jun 9, 2014 at 12:51 PM