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