Improve support for app services

[mstniy]

Orbot does support app services, which is when an app requests Orbot to expose a given local port as an Onion service. However, that seems to be where it ends. Orbot does not provide a mechanism for applications to monitor or manipulate their Onion services, including querying the Onion domains they are assigned, making this feature useless.

Please correct me if I am mistaken.

[mstniy]

The manifest contains a content provider, org.torproject.android.ui.hiddenservices.storage , but there doesn't seem to be any mention of it in the code.

Perhaps it is yet to be implemented?

[n8fr8]

This feature wasn't necessarily intended to be an automated app API. The idea is that you run some kind of local server app, which is listening on localhost. Then, you as a user setup the app service within Orbot, which then gives you back the onion address in the UI for you to share, copy and paste, etc, as needed.

That said, there is an Intent UI for an app to request an onion service.

You can see an example of it here:
https://github.com/guardianproject/haven/blob/master/src/main/java/org/havenapp/main/SettingsFragment.java#L720
https://github.com/guardianproject/haven/blob/master/src/main/java/org/havenapp/main/SettingsFragment.java#L341

[mstniy]

My understanding is the following: Orbot has two types of Onion services: user services are created by the user, and work the way you mentioned.
App services are created by other applications via intents, like https://github.com/guardianproject/haven/blob/master/src/main/java/org/havenapp/main/SettingsFragment.java#L725.
The activity response used by https://github.com/guardianproject/haven/blob/master/src/main/java/org/havenapp/main/SettingsFragment.java#L341 seems to have disappeared after commit 0b1e7be, which removed support for V2 services. The new intent that enables V3 services doesn't seem to return a similar response, thus the impossibility for the requester to obtain the domain name assigned to the service.

[n8fr8]

Ah that is a regression. I missed that it was removed in the v2 removal work. @bitmold let's talk about that!

[bitmold]

@n8fr8 @mstniy
Ok, so I have this fixed in this commit though it is a bit rough around the edges: e39bde3

The old implementation for v2 services I wasn't a fan of. When an app like haven requested a v2 service, Orbot would start up a new thread and every 3 seconds would check to see if the hostname for that service was generated, if it found one, it would send it back to the calling app.

This approach adds a new action to Orbot Service ACTION_UPDATE_ONION_NAMES. When OrbotService receives this it does the same logic it does in startTor(). This is why previously in Orbot you would have to restart the app to get an onion service URL, since the update logic only occured in startTor(). Now, this logic still occurs in startTor() but the service will also invoke it whenever it receives an Intent with this action.

Whenever OrbotService updates its onion names, it now sends a STATUS_V3_NAMES_UPDATED status back to OrbotMainActivity. This means that rather than looping indefinitely, Orbot responds when the info is ready.

1. An external app sends a request to Orbot to create an Onion Service with onion port X on local port Y
2. Orbot opens a dialog with yes/no option for the user
   a. If no, the requesting app is sent a "cancelled" message
   b. If yes:
   1. Orbot starts tor
   2. When it finishes establishing a connection, the activity will receive an event from the service and will retrieve the newly created service's hostname.
   3. Orbot, with tor running, sends the hostname back to the app that invoked it, and exits

[bitmold]

One open question I have at the moment is at when point in tor's lifecycle does it generate the onion domain. Does an actual tor connection need to be fully established? And if not, Orbot should send the info back to the requesting app as soon as possible, without waiting for the tor connection.

[bitmold]

The original implementation of this API for V2 Onion Addresses was pretty limited. For instance, with the old API you would request a V2 Onion Service by giving Orbot an onion port and a local port, however if a service already existed on that local port, the requesting application would get whatever onion domain exists there (whether it was created by the user within Orbot for an unrelated purpose, or by another application).

Some ideas going forward:

• Orbot should be updated to keep track of which apps created each service.
• With the WIP commit I have above, it would be somewhat trivial to provide an API where requesting apps can provide Orbot a v3 onion domain and if Orbot has an entry for it, it can respond with the local port, onion port, user created service name, if the user set it to be enabled/disabled, and also the package ID of the application that created this service

[bitmold]

While this discussion unfolds, I intend to work on the following things in the meantime:

• Implementing a "Loading..." dialog for when Orbot is creating an onion service for another application. Currently and with the old v2 API users would just be sent to the main app while tor connects.
• Updating netcipher
  • It needs a new release that drops all of the v2 calls (even if Orbot still supported the API the services the tor network no longer supports v2 services...). It has a very rudimentary (and unreleased) interface for apps to spin up v3 services, and this will need to get updated as we flesh out design decisions here.
  • Perhaps adding a sample app to netcipher, I have a local one on my machine I've been using to test the code I'm writing for this issue against my copy of Orbot, but once things get finalized it would be nice to have something people can be referred to that's not specific lines of code in Haven.

[bitmold]

🤷‍♀️ anyway that's it for today, but I'm curious what you all think...