I can implement an intermediate solution to the problem. I'm going to make a distinction between manually imported domains and domains imported by an application.
I will show them in two different lists with different contextual menus. I will use a tabbed view, one for user services and one for app services. Contextual menu for app service allow the user to: - Copy .onion ulr to clipboard Contextual menu for a service manually created allow: - Copy .onion ulr to clipboard - Create a backup - Delete the service - Pause the service 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, ....... 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 A lot of work but i like it, the result will compensate. El 21 nov. 2016 2:04 p. m., "arrase" <arr...@gmail.com> escribió: > 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" < > h...@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 < >> nat...@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 >> >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
