2016-11-21 16:47 GMT+01:00 Hans-Christoph Steiner <[email protected] >:
> > > 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. > > But the feature is currently there, why we have to lose it? Maintain backwards compatibility as much as possible is a good idea. Currently the only documented use of orbot for run hidden services is open the settings a manually add a port. And i use that feature, i don't like to code for loose it. On the point of saving more information, I do not see the problem, I have solved it with a content provider that consults a database with a single table, simple and easy to maintain. Most of the work is done, we just need to improve the acquisition of permissions and improve layouts. I suggest to take a look at the work already done. https://github.com/arrase/orbot/tree/hidden_services There is not more complexity, just a simple list with a button to add, but the added features have been many and without breaking compatibility back. .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]
