[guardian-dev] Hi, i' new

Sun Nov 20 17:04:25 EST 2016

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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161120/1aa0f278/attachment-0001.html>