Nathan of Guardian: > > > On Mon, Nov 21, 2016, at 05:21 AM, Hans-Christoph Steiner wrote: >> What use case are you thinking for manually setting up a hidden service >> in Orbot? >> >> Orbot doesn't provide any actual services beyond Tor and internet >> proxying, so it seems that its not really the place for setting up and >> managing hidden services. > > 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. .hc > > > >> >> .hc >> >> arrase: >>> And the services that a user configure manually? Why do you have to lose >>> them? >>> >>> El 21 nov. 2016 2:00 p. m., "Hans-Christoph Steiner" < >>> [email protected]> escribió: >>> >>>> >>>> About the hidden service backups, that certainly would be a useful >>>> feature, but it should not be implemented in Orbot. The requesting apps >>>> need to be entirely responsible for saving, managing and backing up that >>>> key. Orbot will never be able to provide all of the various levels of >>>> security needed by different apps using Hidden Services. For example, >>>> something like OnionShare might only have one-time-use Hidden Services >>>> that are thrown away after use. Another app might have a long-lived >>>> hidden service that is too sensitive to be backed up via Google or other >>>> cloud services. >>>> >>>> .hc >>>> >>>> arrase: >>>>> 2016-11-21 0:25 GMT+01:00 Nathan of Guardian < >>>> [email protected]>: >>>>> >>>>>> >>>>>> We only need Internet permission, so haven't had to deal with the new >>>>>> permission request framework. >>>>>> >>>>>> Why do we need a backup feature? I thought the approach was for apps to >>>>>> manage their keys themselves, at least advanced apps? >>>>>> >>>>> >>>>> By example, if you have ssh running at your device and you want to >>>> maintain >>>>> the same .onion in a device migration. >>>>> >>>>> You can manually create and restore an .onion backup from one device to >>>>> another. >>>>> >>>>>> Even so, couldn't we offer backup without needing external storage >>>>>> permissions? >>>>>> >>>>> >>>>> With the ability to be exported to another device writing a zip in the >>>>> external store is the simplest I think. >>>>> >>>>> >>>>>> I bring this up because I know our users are very sensitive to this, and >>>>>> the external storage permission is one that often sets off concern since >>>>>> you are giving access to full media. >>>>>> >>>>> >>>>> Well, is true but with runtime permissions the user is asked only when is >>>>> going to perform an action who actually needs them, so you can assume >>>> than >>>>> there is no panic if the app ask for those permissions. >>>>> >>>>> Also, the permissions were already there before I started to make >>>> changes, >>>>> so we understand that all those users who have an older version of >>>> android >>>>> have to accept them when installing the application from the store and >>>> does >>>>> not seem to have been a Problem for Orbot to date. >>>>> >>>>> On the other hand, it seems that they are not used in the application, if >>>>> they are not used, why are they there? And if they are used, the parts of >>>>> the code that use them are not working in the latest versions of android >>>>> since there is no code that manages them. >>>>> >>>>> That needs a review. >>>>> >>>>> >>>>>> Thanks for the hard work on this, and I will definitely take a look at >>>>>> the UI issues. >>>>>> >>>>> >>>>> To you. >>>>> >>>> >>>> -- >>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >>>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 >>>> >>> >> >> -- >> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 > > -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
