[guardian-dev] supporting manual hidden services in Orbot WAS: Hi, i' new

arrase arrase at gmail.com
Fri Nov 25 06:42:43 EST 2016

I do not think this is more maintainable than extending Orbot.

Exporting services to a specialized app is not a problem but .....

How does this app communicate with Orboot to manage the services?

Currently Tor should be running under Orbot, the app would send an Intent
to Orbot and this should stop and restart to start the service.

The code is the same, plus the implementation of the communication channel.

Orbot is not an especially large application, I have not found great
difficulties to make changes in it.

It is true that, with all due respect, there are things that can be done
better, but in general it is a friendly application for the developer.

On the other hand, if we design an application that is consistent and
really represents an advantage over the current option I can implement it.

I'm really bad as a designer, so I better not do that part, but I can
implement it without problems and in a reasonable time once we have a

I would also like to propose a slightly different road map:

- Ending my changes, is already an advantage over the current state and
only a few lines of code to finish it

- Remove the creation of torrc.custom and use instead the control port,
just as you would with the Stem library

- Improve the Intent Services API offered by Orbot and make it public
through documentation (not just hidden services intents)

- Create individual applications as proposed here

This is road map for a longer term, but I can do it

2016-11-25 11:56 GMT+01:00 Hans-Christoph Steiner <hans at guardianproject.info

> Greg Troxel:
> >
> > Hans-Christoph Steiner <hans at guardianproject.info> writes:
> >
> >>> I do see value here for medium to advanced users, that want to use
> Orbot
> >>> with apps that do not support setting up hidden servers directly. This
> >>> is mostly remote access to on device HTTP servers, SSH servers and so
> >>> on. Today, we have many users who do this through the existing Orbot
> >>> settings, where you can manually enter a port, and the onion service is
> >>> generated. Arrase is just extending that behavior with a better user
> >>> interface. I think it is a valid use of Orbot.
> >>
> >> That's going to add a fair amount of complexity to Orbot, as well as the
> >> requirement to save valuable state info (i.e. beyond the regular setup).
> >>  Seems like we should have a strong use case for this before taking it
> >> on.  People who want to run servers on their phone can always use
> >> linuxdeploy, Lil' Debi, etc.
> >
> > Perhaps there could be a HS gateway app that allows users to configure a
> > HS and connect it to something that is running on localhost.  That app
> > could have all the UI and saving.  Then Orbot could be closer to
> > stateless.
> I think that approach makes a lot of sense: spin off the specialized
> features out of Orbot into their own apps, like orWall for root/iptables
> support.  Orbot needs to just be a really solid core service provider.
> We really need to strip down Orbot as much as possible to keep it
> maintainable, especially since this current update was a long time in
> coming.
> @arrase, your UI for manually managing Hidden Services is fine, but it
> really does not belong in Orbot.  I know that some kind of feature like
> was in Orbot before, but it was not really a supported feature, and I
> think its clear that we cannot do a good job of maintaining precious
> user data in Orbot.  Tor configs can be manually recreated, Hidden
> Service keys cannot.
> The migration path for moving manual Hidden Services out of Orbot should
> be pretty straightforward, there could just be an "export" menu option
> that puts up some UI to have the user choose which app to  export the
> existing hidden services config to.
> .hc
> --
> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161125/64f12b5a/attachment-0001.html>

More information about the guardian-dev mailing list