[guardian-dev] Hi, i' new

[Hans-Christoph Steiner]

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.

.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