[guardian-dev] Hi, i' new

Nathan of Guardian nathan at guardianproject.info
Mon Nov 21 08:23:33 EST 2016


We could write the backup zip to the internal app storage, and then mark
it as world readable. This path could then be shared via an intent to
the app of choice by the user, or just displayed to the user for copying
manually.

For example, it could be written here:
/data/data/org.torproject.android/file/onionbackup.zip

We do not ask for the storage permission, currently, so I am not sure
what you mean by that. Where do you see that?

Here is what we do currently, from here:
https://github.com/n8fr8/orbot/blob/master/app/src/main/AndroidManifest.xml

These are considered low risk and the user is not prompted:
<uses-permission android:name="android.permission.INTERNET"/>
	<uses-permission
	android:name="android.permission.ACCESS_NETWORK_STATE"/>
	<uses-permission
	android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

This one is only for devices that are root capable, and there is a whole
permission model associated with them. 
	<uses-permission
	android:name="android.permission.ACCESS_SUPERUSER" />

That said, I am eager to remove root features from Orbot, as well.

Thanks!

On Mon, Nov 21, 2016, at 05:04 AM, arrase wrote:
> 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
> >


-- 
  Nathan of Guardian
  nathan at guardianproject.info


More information about the guardian-dev mailing list