[guardian-dev] Orbot hidden services

[Michael Rogers]

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

On 23/04/13 14:13, Nathan of Guardian wrote:
> All of what you proposed is definitely possible and plausible in
> the next update of Orbot coming in May. The main issue with Hidden
> Services setup is the variable delay from requesting one, to
> receiving the onion. This can easily be handled by an Intent
> result, but the calling app should consider the provisioning
> process to be highly asynchronous.

Would it be possible to expose this functionality via a service API
rather than an intent result? I believe startActivityForResult() can
only be called from an activity, and the result's passed back to the
same activity, so the user would have to keep the activity open for
the duration of the asynchronous operation. It would be nice to be
able to make the calls from a background service and receive the
results there.

> Here is a bit of sample code that shows what is possible now:
> 
> https://github.com/guardianproject/OrbotTalk/blob/master/src/info/guardianproject/messenger/OrbotTalkActivity.java#L231
>
>  In short:
> 
> 1) request hidden service using the intent args above
> 
> 2) request Orbot to start (see OrbotHelper class in OnionKit
> project) to make sure it is running. You may need to manually stop
> and start Orbot as well.
> 
> 3) call the same request again as in #1 until you get a proper
> result callback with the .onion
> 
> Obviously this is a bit kludgy, which is why we don't promote the
> current partial implementation.

Thanks for the pointers!

As far as I can tell, jtorctl calls TorService.message() whenever Tor
logs a message, which calls TorService.getHiddenServiceHostname(),
which checks for the existence of the hostname file, and if it exists,
puts the onion hostname into shared prefs, making it available by
calling #1 above. Is there a non-polling way to listen for the
creation of a file on Android? Or, failing that, a non-polling way to
listen for changes to shared prefs?

> The other important thing to note about mobile HS is that if your
> IP address changes, say from WiFi to 3G, it could make your current
> HS unreachable. It may make sense to generate a new HS per network
> or unique IP. I am hoping we can improve Tor's ability to handle HS
> with dynamic IPs, but for now this is the reality.

Interesting. Is this caused by the circuits to the service's
introduction points breaking? If so, would restarting Tor cause it to
rebuild the circuits?

There's a method in jtorctl2's Controller interface that might be
useful here: externalAddressChanged(). The interface seems to be
richer than jtorctl's EventHandler, though I don't know anything about
the other merits of the two libraries.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRduiKAAoJEBEET9GfxSfM7AQH/0LtnFYMm4Ibe7TE0wu5SGBH
i3GHuxM+UYRIGWVPb++u2maLmZVo0i6xdnUsjRNv/ustMnqsZzqDpYPPRtQsjTdB
aIr2fBQo6131NajJfu4/uKr6B3Wj+Y0Wv4xnLiVNlexQWH+Xa0VsTXXTl+wS15Ws
BRj59I5zhPEmEGzz1oxjellLTVArEvXQHE/hIHFjRBsnoA0hi13azjJFBfONceSZ
NCHzniw2fA/cyJsvtgwSfiqex/Ha4xU7mgDnLpACTtPDbcqjVTOm2VoP/lYDM7r/
xf9LlJJvc7oILrbwOGJsDq3fdlM7Em7py7Gv3vNr6ToaWmA+o3NSm1fx3O4FiF4=
=Nlu1
-----END PGP SIGNATURE-----