[guardian-dev] Hi, i' new

[arrase]

2016-11-21 16:47 GMT+01:00 Hans-Christoph Steiner <hans at guardianproject.info
>:

>
>
> 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" <
> >>> hans at guardianproject.info> 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 <
> >>>> nathan at guardianproject.info>:
> >>>>>
> >>>>>>
> >>>>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161121/a03b51c0/attachment-0001.html>