[guardian-dev] Hi, i' new
Nathan of Guardian
nathan at guardianproject.info
Sun Nov 20 18:25:35 EST 2016
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?
Even so, couldn't we offer backup without needing external storage
permissions?
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.
Thanks for the hard work on this, and I will definitely take a look at
the UI issues.
+n
On Sun, Nov 20, 2016, at 02:04 PM, arrase wrote:
> Ok, permissions are working, and the backup creation feature works nice.
>
> There is only one thing to do, a way for a restore the backup.
>
> But there is a problem, i'm very bad building layotus, i mean, my layouts
> are always ugly as hell.
>
> So, if someone can build Orbot from the new brach and take a look to the
> job for suggest a better look for the layouts the help will be
> appreciated.
>
> Here is the branch at github:
>
> https://github.com/arrase/orbot/tree/hidden_services
>
> The list item is ugly as hell, the icon and color of the fab is ugly and
> i
> don't know where to put the button for load a backup zip, maybe
> longclicking the fab....bad idea i think.
>
> 2016-11-20 16:17 GMT+01:00 arrase <arrase at gmail.com>:
>
> > I'm confused about Orbot permission management.
> >
> > Orbot needs several permission like WRITE_EXTERNAL_STORAGE but there is no
> > code related to the new runtime permissions api.
> >
> > When i try to do a backup to the external storage it fails because i need
> > to request permissions but...
> >
> > How have permissions worked until today? i have to implement the request
> > to the new api in OrbotMainActivity if Build.VERSION.SDK_INT>Build.
> > VERSION_CODES.LOLLIPOP_MR1???
> >
> >
> >
> >
> > 2016-11-17 23:36 GMT+01:00 arrase <arrase at gmail.com>:
> >
> >> Then you can implement TOFU in a simpler way and with backwards
> >> compatibility, nice, I will implement it
> >>
> >> El 17 nov. 2016 11:31 p. m., "Hans-Christoph Steiner" <
> >> hans at guardianproject.info> escribió:
> >>
> >>>
> >>> The idea is to do Trust-On-First-Use (TOFU) with TrustedIntents, not to
> >>> use the pin. Basically, use the same technique to verify the
> >>> packagename and signing key are trusted, but store the values on the
> >>> first use, rather than have it built into the app. I forget off the top
> >>> of my head whether that is fully implemented in TrustedIntents, but if
> >>> not, it shouldn't be hard to do.
> >>>
> >>> .hc
> >>>
> >>> arrase:
> >>> > I have read about TrustedIntents, as a concept is good but if as
> >>> > Hans-Christoph said to make the user have to do too many interactions
> >>> is
> >>> > not good, and implementing TrustedIntents in its current state
> >>> requires the
> >>> > user to use an application (Checkey) To get the pin.
> >>> >
> >>> > Too much work for the user.
> >>> >
> >>> > I will do something that is simpler, provide sufficient security and
> >>> > backwards compatible.
> >>> >
> >>> > ....thinking in progress.....
> >>> >
> >>> > 2016-11-17 22:06 GMT+01:00 Hans-Christoph Steiner <
> >>> hans at guardianproject.info
> >>> >> :
> >>> >
> >>> >>
> >>> >> Updating to the new style makes sense. I don't know the current
> >>> hidden
> >>> >> API though.
> >>> >>
> >>> >> .hc
> >>> >>
> >>> >> arrase:
> >>> >>> Ummm .... when you update an application from the store, you delete a
> >>> >>> preference .... although the value is not going to be accessed has
> >>> not
> >>> >> been
> >>> >>> erased, right?
> >>> >>>
> >>> >>> Can we do a routine that after updating look for the configuration
> >>> of the
> >>> >>> old preferences and convert them to the new ones?
> >>> >>>
> >>> >>> makes sense?
> >>> >>>
> >>> >>> 2016-11-17 21:23 GMT+01:00 arrase <arrase at gmail.com>:
> >>> >>>
> >>> >>>> No, old ones do not run....must be requested again from the app, i
> >>> >>>> complete rewrite the settings , i can't find a way to maintain the
> >>> old
> >>> >> one
> >>> >>>> preference setup and the new one screen, has no sense if is put all
> >>> >>>> together.
> >>> >>>>
> >>> >>>> A cursor content provider has more sense for store a big amount of
> >>> >> domains
> >>> >>>> and with a view adapter is more easy to manage for the user.
> >>> >>>>
> >>> >>>> El 17 nov. 2016 7:16 p. m., "Nathan of Guardian" <
> >>> >>>> nathan at guardianproject.info> escribió:
> >>> >>>>
> >>> >>>>> Hmm, I may be okay with breaking backward compatibility. I don't
> >>> think
> >>> >>>>> there are that many apps using the existing intent, and it would
> >>> only
> >>> >> be
> >>> >>>>> a problem from them to request a new intent (i.e. existing
> >>> configured
> >>> >>>>> onion services would still work, right?)
> >>> >>>>>
> >>> >>>>> On Thu, Nov 17, 2016, at 09:55 AM, arrase wrote:
> >>> >>>>>> I have only done a quick read but ... this breaks backward
> >>> >>>>> compatibility,
> >>> >>>>>> is it correct? I have no problem with that, but if we break the
> >>> >>>>>> compatibility I'm going to change the Intent to accept a list of
> >>> ports
> >>> >>>>>> instead of just one
> >>> >>>>>>
> >>> >>>>>> El 17 nov. 2016 6:31 p. m., "Hans-Christoph Steiner" <
> >>> >>>>>> hans at guardianproject.info> escribió:
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> Yes. Check out our TrustedIntents library for some methods.
> >>> Also,
> >>> >>>>> this
> >>> >>>>>>> project has some other methods for validating Intents received
> >>> by a
> >>> >>>>>> Service:
> >>> >>>>>>>
> >>> >>>>>>> https://gitlab.com/fdroid/privileged-extension/
> >>> >>>>>>>
> >>> >>>>>>> .hc
> >>> >>>>>>>
> >>> >>>>>>> arrase:
> >>> >>>>>>>> Is it possible to know which app has sent an Intent service?
> >>> I'll
> >>> >>>>>>>> investigate
> >>> >>>>>>>>
> >>> >>>>>>>> It seems to me a good method if it is possible to implement it
> >>> >>>>> without
> >>> >>>>>>>> having to ask the app to identify itself.
> >>> >>>>>>>>
> >>> >>>>>>>> 2016-11-17 17:42 GMT+01:00 Hans-Christoph Steiner <
> >>> >>>>>> hans at guardianproject.info
> >>> >>>>>>>>> :
> >>> >>>>>>>>
> >>> >>>>>>>>>
> >>> >>>>>>>>> I think adding any kind of user interaction is too much
> >>> complexity.
> >>> >>>>>>>>> This needs to be entirely transparent to the user, at least to
> >>> >>>>> start
> >>> >>>>>>>>> with. Orbot has no saved state beyond the basic config stuff
> >>> (e.g.
> >>> >>>>>>>>> using VPN mode, allowing background starts, etc). So its
> >>> entirely
> >>> >>>>> up
> >>> >>>>>> to
> >>> >>>>>>>>> the app to save the Hidden Service key.
> >>> >>>>>>>>>
> >>> >>>>>>>>> If an app sends Orbot a private key, it will remember which app
> >>> >>>>> sent
> >>> >>>>>> it,
> >>> >>>>>>>>> and only allow that exact app to do anything with it. An app
> >>> can
> >>> >>>>> pass
> >>> >>>>>>>>> around that private key as it wants to.
> >>> >>>>>>>>>
> >>> >>>>>>>>> If Orbot generates the private key, then Orbot will send that
> >>> back
> >>> >>>>> to
> >>> >>>>>>>>> the requesting app, and allow only that app to access it.
> >>> >>>>>>>>>
> >>> >>>>>>>>> .hc
> >>> >>>>>>>>>
> >>> >>>>>>>>> arrase:
> >>> >>>>>>>>>> Nice, I'm using that Intent (INTENT_ACTION_REQUEST_HIDDEN_
> >>> >>>>> SERVICE),
> >>> >>>>>> I've
> >>> >>>>>>>>>> extended it to maintain backward compatibility.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> I'm going to add another Intent to manage the small security
> >>> layer
> >>> >>>>>> that
> >>> >>>>>>>>> I'm
> >>> >>>>>>>>>> adding when exporting the key of a service for its backup.
> >>> >>>>>>>>>> Once the permission for export the key is denied, only the
> >>> user
> >>> >>>>> can
> >>> >>>>>>>>>> re-grant it from the main application.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> The major picture is done, now i'm adding:
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> - A way for import/export the configuration of a hidden
> >>> service
> >>> >>>>> in zip
> >>> >>>>>>>>>> fromat (UI and Intent service versions)
> >>> >>>>>>>>>> - A way for delete a hidden service (UI and Intent service
> >>> >>>>> versions)
> >>> >>>>>>>>>> - Intent for disallowing backup of the service.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> 2016-11-17 15:47 GMT+01:00 Nathan of Guardian <
> >>> >>>>>>>>> nathan at guardianproject.info>:
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>> As Arrase point out though, there is an undocumented intent.
> >>> >>>>> This is
> >>> >>>>>>>>>>> what we use for CameraV currently. I think making it
> >>> official,
> >>> >>>>>> expanding
> >>> >>>>>>>>>>> it, and adding it into NetCipher makes a great deal of sense.
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> On Thu, Nov 17, 2016, at 12:37 AM, Hans-Christoph Steiner
> >>> wrote:
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> The documentation is mostly in the form of javadoc strings
> >>> in
> >>> >>>>> the
> >>> >>>>>>>>>>>> NetCipher library, since that's the usual developer
> >>> interface to
> >>> >>>>>> this
> >>> >>>>>>>>>>>> stuff. Otherwise, there is a little bit here:
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> https://guardianproject.info/code
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> There isn't yet any official way to request a Hidden
> >>> Service as
> >>> >>>>> of
> >>> >>>>>> now.
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> .hc
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> arrase:
> >>> >>>>>>>>>>>>> After reviewing the code and learned how to make the
> >>> changes I
> >>> >>>>>> think
> >>> >>>>>>>>>>> I'll
> >>> >>>>>>>>>>>>> take this a little further.
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>> Keeping the backwards compatibility I will rewrite the
> >>> >>>>>> configuration
> >>> >>>>>>>>>>>>> preferences of the hidden services and an extension of the
> >>> >>>>> existing
> >>> >>>>>>>>>>> Intent
> >>> >>>>>>>>>>>>> services.
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>> It's a big change that will take me a few days but I think
> >>> >>>>> it's the
> >>> >>>>>>>>>>> right
> >>> >>>>>>>>>>>>> thing to do.
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>> Additionally I have not found a site where are documented
> >>> the
> >>> >>>>>>>>>>> integration
> >>> >>>>>>>>>>>>> options offered by Orbot, for example there is already the
> >>> >>>>> option
> >>> >>>>>> that
> >>> >>>>>>>>>>> an
> >>> >>>>>>>>>>>>> application can register a new port hidden by an Intent
> >>> but I
> >>> >>>>> have
> >>> >>>>>> not
> >>> >>>>>>>>>>>>> known until reading the code despite having searched
> >>> >>>>> Information on
> >>> >>>>>>>>>>> google.
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>> 2016-11-15 23:26 GMT+01:00 Nathan of Guardian <
> >>> >>>>>>>>>>> nathan at guardianproject.info>:
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>> As I mentioned in the ticket, you need to run > ndk-build
> >>> in
> >>> >>>>> the
> >>> >>>>>>>>>>>>>> /orbotservice directory to create those native assets
> >>> first.
> >>> >>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>> We are working on extracting the native binary build
> >>> >>>>> components
> >>> >>>>>> into
> >>> >>>>>>>>> a
> >>> >>>>>>>>>>>>>> separate gradle dependency, to make working on the app
> >>> itself,
> >>> >>>>>>>>> easier.
> >>> >>>>>>>>>>>>>> For now though, yes, you must build!
> >>> >>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>> On Tue, Nov 15, 2016, at 01:19 PM, arrase wrote:
> >>> >>>>>>>>>>>>>>> It's hard to build Orbot, I solved several problems with
> >>> the
> >>> >>>>>>>>>>> toolchain
> >>> >>>>>>>>>>>>>>> but
> >>> >>>>>>>>>>>>>>> now I'm stuck here building Tor binary:
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>> zip ../orbotservice/src/main/assets/armeabi/pdnsd.mp3
> >>> >>>>>>>>>>>>>>> ../orbotservice/src/main/libs/armeabi/pdnsd
> >>> >>>>>>>>>>>>>>> zip warning: name not matched:
> >>> >>>>>>>>>>>>>>> ../orbotservice/src/main/libs/armeabi/pdnsd
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>> zip error: Nothing to do!
> >>> >>>>>>>>>>>>>>> (../orbotservice/src/main/assets/armeabi/pdnsd.mp3)
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>> Is it a known error?
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>> For this case I have not found references in google
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>> 2016-11-15 20:14 GMT+01:00 arrase <arrase at gmail.com>:
> >>> >>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>> Great , is all i need to start, many thanks.
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>> 2016-11-15 20:02 GMT+01:00 Hans-Christoph Steiner <
> >>> >>>>>>>>>>>>>>>> hans at guardianproject.info>:
> >>> >>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>> I think it would work like the start/status intents
> >>> that
> >>> >>>>> are
> >>> >>>>>>>>>>> currently
> >>> >>>>>>>>>>>>>>>>> in Orbot. The app sends an Intent to Orbot to request a
> >>> >>>>> Hidden
> >>> >>>>>>>>>>> Service
> >>> >>>>>>>>>>>>>>>>> to be created, then Orbot sends reply status Intents to
> >>> >>>>> the app
> >>> >>>>>>>>>>> that
> >>> >>>>>>>>>>>>>>>>> made the request with all relevant info, including a
> >>> >>>>>> FileProvider
> >>> >>>>>>>>>>> URI
> >>> >>>>>>>>>>>>>>>>> with GRANT URI permissions so that the requesting app
> >>> can
> >>> >>>>> get
> >>> >>>>>> the
> >>> >>>>>>>>>>>>>>>>> private key. That'd be the whole API, unless you also
> >>> >>>>> want to
> >>> >>>>>>>>>>> make a
> >>> >>>>>>>>>>>>>>>>> "stop hidden service" Intent.
> >>> >>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>> No need to change anything about the control, the
> >>> whole API
> >>> >>>>>> would
> >>> >>>>>>>>>>> be
> >>> >>>>>>>>>>>>>>>>> based on those Intents, and we can use the
> >>> TrustedIntents
> >>> >>>>>> library
> >>> >>>>>>>>>>> to
> >>> >>>>>>>>>>>>>>>>> enforce that the reply only goes to the exact app that
> >>> >>>>>> requested
> >>> >>>>>>>>>>> it.
> >>> >>>>>>>>>>>>>> As
> >>> >>>>>>>>>>>>>>>>> a start, it would be fine to send the reply based on
> >>> >>>>>> packageName.
> >>> >>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>> .hc
> >>> >>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>> arrase:
> >>> >>>>>>>>>>>>>>>>>> Are you suggesting something? XD
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> I can take a look at the problem and propose a
> >>> solution,
> >>> >>>>> it
> >>> >>>>>> will
> >>> >>>>>>>>>>>>>> not be
> >>> >>>>>>>>>>>>>>>>>> fast but I can do it.
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> Tonight I will try to compile Orbot from sources and
> >>> try
> >>> >>>>> to
> >>> >>>>>>>>>>>>>> familiarize
> >>> >>>>>>>>>>>>>>>>>> myself with the code. (Is there a wiki with info??)
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> How do you want to focus the change? What should be
> >>> >>>>> possible
> >>> >>>>>> by a
> >>> >>>>>>>>>>>>>> third
> >>> >>>>>>>>>>>>>>>>>> party?
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> In my opinion:
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> - Be able to register a hidden service for your ports
> >>> >>>>> without
> >>> >>>>>>>>>>>>>> sharing it
> >>> >>>>>>>>>>>>>>>>>> with other applications.
> >>> >>>>>>>>>>>>>>>>>> - Be able to backup the configuration files in order
> >>> to
> >>> >>>>>> migrate
> >>> >>>>>>>>>>> the
> >>> >>>>>>>>>>>>>>>>> service.
> >>> >>>>>>>>>>>>>>>>>> - Everything should be possible without root
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> It would be nice if all this was possible without
> >>> giving
> >>> >>>>>> access
> >>> >>>>>>>>> to
> >>> >>>>>>>>>>>>>> the
> >>> >>>>>>>>>>>>>>>>> Tor
> >>> >>>>>>>>>>>>>>>>>> configuration port, but right now I can not think of
> >>> how
> >>> >>>>> to do
> >>> >>>>>>>>> it.
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> I keep thinking ..... after working, I'll dedicate
> >>> some
> >>> >>>>> time
> >>> >>>>>> to
> >>> >>>>>>>>>>> the
> >>> >>>>>>>>>>>>>>>>> problem
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>> 2016-11-15 14:19 GMT+01:00 Hans-Christoph Steiner <
> >>> >>>>>>>>>>>>>>>>> hans at guardianproject.info
> >>> >>>>>>>>>>>>>>>>>>> :
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>> arrase:
> >>> >>>>>>>>>>>>>>>>>>>> 2016-11-15 13:23 GMT+01:00 Michael Rogers <
> >>> >>>>>>>>>>>>>> michael at briarproject.org>:
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>>> Hi arrase,
> >>> >>>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>>> Thanks for discovering this bug. Can you describe
> >>> how
> >>> >>>>>> Briar's
> >>> >>>>>>>>>>> Tor
> >>> >>>>>>>>>>>>>>>>> daemon
> >>> >>>>>>>>>>>>>>>>>>>>> conflicts with Orbot? What problems does it cause?
> >>> Our
> >>> >>>>>> goal is
> >>> >>>>>>>>>>>>>> for
> >>> >>>>>>>>>>>>>>>>> Briar
> >>> >>>>>>>>>>>>>>>>>>>>> to be able to operate on the same device as Orbot
> >>> >>>>> without
> >>> >>>>>>>>>>>>>> problems.
> >>> >>>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> I do not think it could be called a bug, and
> >>> definitely
> >>> >>>>> not
> >>> >>>>>> a
> >>> >>>>>>>>>>>>>> Briar
> >>> >>>>>>>>>>>>>>>>> bug
> >>> >>>>>>>>>>>>>>>>>>> at
> >>> >>>>>>>>>>>>>>>>>>>> all. I find it hard to argue in English, I'm sorry.
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> But if it is true that is a problem if more
> >>> applications
> >>> >>>>>> follow
> >>> >>>>>>>>>>>>>> the
> >>> >>>>>>>>>>>>>>>>> same
> >>> >>>>>>>>>>>>>>>>>>>> path as Briar implementing a Tor daemon within the
> >>> >>>>>> application.
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> Briar opens those ports for Tor:
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> Tcp 0 0 127.0.0.1:59050 0.0.0.0:* LISTEN 10019
> >>> 214952
> >>> >>>>> 18753
> >>> >>>>>>>>>>>>>>>>>>>> Tcp 0 0 127.0.0.1:59051 0.0.0.0:* LISTEN 10019
> >>> 213387
> >>> >>>>> 18753
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> If Orbot starts first, nothing prevents it from
> >>> taking
> >>> >>>>> ports
> >>> >>>>>>>>>>>>>> 59050 and
> >>> >>>>>>>>>>>>>>>>>>>> 59051 as control ports. It is a remote but real
> >>> >>>>> possibility
> >>> >>>>>> and
> >>> >>>>>>>>>>>>>> would
> >>> >>>>>>>>>>>>>>>>> be
> >>> >>>>>>>>>>>>>>>>>>>> more real when more applications opt for the same
> >>> >>>>> solution.
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> It's just an argument about changing the hidden
> >>> service
> >>> >>>>> API
> >>> >>>>>> for
> >>> >>>>>>>>>>>>>> Orbot.
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> I think there are more strong arguments like that
> >>> each
> >>> >>>>>>>>>>>>>> application can
> >>> >>>>>>>>>>>>>>>>>>>> manage the configuration files of the hidden
> >>> service to
> >>> >>>>> be
> >>> >>>>>> able
> >>> >>>>>>>>>>> to
> >>> >>>>>>>>>>>>>>>>>>> migrate
> >>> >>>>>>>>>>>>>>>>>>>> between devices.
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> It does not look very good to make an application
> >>> that
> >>> >>>>> uses
> >>> >>>>>> the
> >>> >>>>>>>>>>>>>> hidden
> >>> >>>>>>>>>>>>>>>>>>>> service as a user identifier and if we lose the
> >>> device
> >>> >>>>> we
> >>> >>>>>> lose
> >>> >>>>>>>>>>> our
> >>> >>>>>>>>>>>>>>>>> entire
> >>> >>>>>>>>>>>>>>>>>>>> network of contacts.
> >>> >>>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>> I think they are good arguments for bringing about
> >>> an
> >>> >>>>>>>>>>> improvement
> >>> >>>>>>>>>>>>>> in
> >>> >>>>>>>>>>>>>>>>>>> Orbot
> >>> >>>>>>>>>>>>>>>>>>>> APi as proposed by Nathan.
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>> I think we all want to have a nice Intent-based API
> >>> in
> >>> >>>>> Orbot
> >>> >>>>>> for
> >>> >>>>>>>>>>>>>> apps
> >>> >>>>>>>>>>>>>>>>> to
> >>> >>>>>>>>>>>>>>>>>>> work with Hidden Services, the real question is: who
> >>> is
> >>> >>>>>> going to
> >>> >>>>>>>>>>>>>> do the
> >>> >>>>>>>>>>>>>>>>>>> work. That would be a great place for you to start
> >>> to
> >>> >>>>> get
> >>> >>>>>>>>>>>>>> involved.
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>> .hc
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>> --
> >>> >>>>>>>>>>>>>>>>>>> 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-unsubscribe@
> >>> >>>>>>>>>>>>>> lists.mayfirst.org
> >>> >>>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>>>> --
> >>> >>>>>>>>>>>>>>>>> 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-unsubscribe at lists.mayfirst.org
> >>> >>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>> --
> >>> >>>>>>>>>>>>>> Nathan of Guardian
> >>> >>>>>>>>>>>>>> nathan at guardianproject.info
> >>> >>>>>>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>>>>>> List info:
> >>> >>>>>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> >>> >>>>>>>>>>>>>> To unsubscribe, email:
> >>> >>>>>> guardian-dev-unsubscribe at lists.mayfirst.org
> >>> >>>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>>>>> List info: https://lists.mayfirst.org/mai
> >>> >>>>> lman/listinfo/guardian-dev
> >>> >>>>>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> >>>>> .mayfirst.org
> >>> >>>>>>>>>>>>>
> >>> >>>>>>>>>>>>
> >>> >>>>>>>>>>>> --
> >>> >>>>>>>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA
> >>> 00AA
> >>> >>>>> 5556
> >>> >>>>>>>>>>>> https://pgp.mit.edu/pks/lookup
> >>> ?op=vindex&search=0xE9E28DEA00
> >>> >>>>> AA5556
> >>> >>>>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>>>> List info: https://lists.mayfirst.org/mai
> >>> >>>>> lman/listinfo/guardian-dev
> >>> >>>>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> >>>>> .mayfirst.org
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>> --
> >>> >>>>>>>>>>> Nathan of Guardian
> >>> >>>>>>>>>>> nathan at guardianproject.info
> >>> >>>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>>> List info: https://lists.mayfirst.org/mai
> >>> >>>>> lman/listinfo/guardian-dev
> >>> >>>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> >>>>> .mayfirst.org
> >>> >>>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> _______________________________________________
> >>> >>>>>>>>>> List info: https://lists.mayfirst.org/mai
> >>> >>>>> lman/listinfo/guardian-dev
> >>> >>>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> >>>>> .mayfirst.org
> >>> >>>>>>>>>>
> >>> >>>>>>>>>
> >>> >>>>>>>>> --
> >>> >>>>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA
> >>> 5556
> >>> >>>>>>>>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00
> >>> AA5556
> >>> >>>>>>>>> _______________________________________________
> >>> >>>>>>>>> List info: https://lists.mayfirst.org/mai
> >>> >>>>> lman/listinfo/guardian-dev
> >>> >>>>>>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> >>>>> .mayfirst.org
> >>> >>>>>>>>>
> >>> >>>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> --
> >>> >>>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA
> >>> 5556
> >>> >>>>>>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00
> >>> AA5556
> >>> >>>>>> _______________________________________________
> >>> >>>>>> List info: https://lists.mayfirst.org/mai
> >>> lman/listinfo/guardian-dev
> >>> >>>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> .mayfirst.org
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> --
> >>> >>>>> Nathan of Guardian
> >>> >>>>> nathan at guardianproject.info
> >>> >>>>> _______________________________________________
> >>> >>>>> List info: https://lists.mayfirst.org/mai
> >>> lman/listinfo/guardian-dev
> >>> >>>>> To unsubscribe, email: guardian-dev-unsubscribe at lists
> >>> .mayfirst.org
> >>> >>>>>
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> _______________________________________________
> >>> >>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> >>> >>> To unsubscribe, email: guardian-dev-unsubscribe at lists.mayfirst.org
> >>> >>>
> >>> >>
> >>> >> --
> >>> >> 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-unsubscribe at lists.mayfirst.org
> >>> >>
> >>> >
> >>>
> >>> --
> >>> 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-unsubscribe at lists.mayfirst.org
--
Nathan of Guardian
nathan at guardianproject.info
More information about the guardian-dev
mailing list