[guardian-dev] Hi, i' new

arrase arrase at gmail.com
Mon Nov 21 09:03:43 EST 2016

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" <arrase at 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" <
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161121/7e4d28ca/attachment.html>

More information about the guardian-dev mailing list