<div dir="ltr"><p dir="ltr">I can implement an intermediate solution to the problem.</p>
<p dir="ltr">I'm going to make a distinction between manually imported domains and domains imported by an application.</p>
<p dir="ltr">I will show them in two different lists with different contextual menus.</p>
<p dir="ltr">I will use a tabbed view, one for user services and one for app services.<br>
</p><p>Contextual menu for app service allow the user to:</p><p>- Copy .onion ulr to clipboard</p><p>Contextual menu for a service manually created allow:</p><p>- Copy .onion ulr to clipboard</p><p>- Create a backup</p><p>- Delete the service</p><p>- Pause the service</p><p>The user can import a service from a backup in zip format and is added to the user services tab, why? migration, vanity onion url, .......</p><p>That approach has a nice side effect, now i can isolate the external storage permission request in a much better way. I honestly do not like how I implemented it now and I was already thinking of a better way to do it and this facilitates what in my opinion is the best way</p><p>A lot of work but i like it, the result will compensate.</p><div class="gmail_extra"><div class="gmail_quote">El 21 nov. 2016 2:04 p. m., "arrase" <<a href="mailto:arrase@gmail.com" target="_blank">arrase@gmail.com</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">And the services that a user configure manually? Why do you have to lose them?</p>
<div class="gmail_extra"><br><div class="gmail_quote">El 21 nov. 2016 2:00 p. m., "Hans-Christoph Steiner" <<a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
About the hidden service backups, that certainly would be a useful<br>
feature, but it should not be implemented in Orbot.  The requesting apps<br>
need to be entirely responsible for saving, managing and backing up that<br>
key.  Orbot will never be able to provide all of the various levels of<br>
security needed by different apps using Hidden Services.  For example,<br>
something like OnionShare might only have one-time-use Hidden Services<br>
that are thrown away after use.  Another app might have a long-lived<br>
hidden service that is too sensitive to be backed up via Google or other<br>
cloud services.<br>
<br>
.hc<br>
<br>
arrase:<br>
> 2016-11-21 0:25 GMT+01:00 Nathan of Guardian <<a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>>:<br>
><br>
>><br>
>> We only need Internet permission, so haven't had to deal with the new<br>
>> permission request framework.<br>
>><br>
>> Why do we need a backup feature? I thought the approach was for apps to<br>
>> manage their keys themselves, at least advanced apps?<br>
>><br>
><br>
> By example, if you have ssh running at your device and you want to maintain<br>
> the same .onion in a device migration.<br>
><br>
> You can manually create and restore an .onion backup from one device to<br>
> another.<br>
><br>
>> Even so, couldn't we offer backup without needing external storage<br>
>> permissions?<br>
>><br>
><br>
>  With the ability to be exported to another device writing a zip in the<br>
> external store is the simplest I think.<br>
><br>
><br>
>> I bring this up because I know our users are very sensitive to this, and<br>
>> the external storage permission is one that often sets off concern since<br>
>> you are giving access to full media.<br>
>><br>
><br>
> Well, is true but with runtime permissions the user is asked only when is<br>
> going to perform an action who actually needs them, so you can assume than<br>
> there is no panic if the app ask for those permissions.<br>
><br>
> Also, the permissions were already there before I started to make changes,<br>
> so we understand that all those users who have an older version of android<br>
> have to accept them when installing the application from the store and does<br>
> not seem to have been a Problem for Orbot to date.<br>
><br>
> On the other hand, it seems that they are not used in the application, if<br>
> they are not used, why are they there? And if they are used, the parts of<br>
> the code that use them are not working in the latest versions of android<br>
> since there is no code that manages them.<br>
><br>
> That needs a review.<br>
><br>
><br>
>> Thanks for the hard work on this, and I will definitely take a look at<br>
>> the UI issues.<br>
>><br>
><br>
> To you.<br>
><br>
<br>
--<br>
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556<br>
<a href="https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556" rel="noreferrer" target="_blank">https://pgp.mit.edu/pks/lookup<wbr>?op=vindex&search=0xE9E28DEA00<wbr>AA5556</a><br>
</blockquote></div></div>
</blockquote></div></div>
</div>