[guardian-dev] zerobin as possible temp store for ChatSecure iOS

Yaron Goland yarong at microsoft.com
Fri Apr 17 11:49:43 EDT 2015


For Thali we depend on Tor Hidden Services to allow people to have the best of both worlds. An identity they can widely share but still have the ability to keep private who they are talking with. And the beauty of Tor Hidden Services is that people can create new entry points if necessary to create even more private sub-groups. So you can imagine someone having the Tor Hidden Service equivalent of a "public address" that anyone who wants to contact them can go to. But in case that address gets DOS'd or gets more attention than they might like they can easily create new endpoints for more restricted groups.

With some caveats around rendezvous this more or less works on Android.

Of course with iOS this is pretty much not going to happen. [1] Yes, we can probably run Tor but only in the foreground. So we need another, less secure, experience for iOS users. Our core messaging mechanism is CouchDB (specifically PouchDB running in node.js). So for iOS we are thinking of an approach where someone can take the synchronization stream they want to send to the other user and serialize it as a file. They can then encrypt it using the target's public key. They then would post it somewhere the iOS user can get access to. That "somewhere" needs to support normal HTTP so we can use iOS's background download tasks. So our first problem is - where can we post these things with a "no sign up" experience?

The next problem was, how does the iOS user even know there is something for them to download? We need some place they can poll to get notifications. We can't really use "push" notifications (which I believe are actually polls anyways) because this would not be a "no sign up" experience. Once has to set up servers, register with Apple, etc. So what we really needed is some server some place that will queue up small notifications and deliver them as a file over HTTP.

So the idea is that the iOS device has a regular background download task that polls their notification endpoint. This endpoint would send a file containing any notifications it received. The background task's code would then read the notifications, pull out the file locations and queue up those files as background task downloads.

So you can see why I got so excited about the possibility of a "no sign up" XMPP and Zerobin solution. It would exactly do what we need!!! But it sounds like we aren't there quite yet. I just wonder what groups are trying to get there?

    Thanks,

            Yaron

[1] There is an assumption here that is worth surfacing. In Thali we look to users using Thali for asynchronous messaging. That is, things like blogs, micro-blogs, photo sharing, status updates, etc. If someone is trying something synchronous (like chat or gamming) then in theory we could use the XMPP mechanism to notify them and if the user accepts "the call" they could switch to the foreground and use Tor to talk to the person. But given how slow Tor is, especially over a hidden service, I have trouble imagining it being workable for voice much less video.

________________________________________
From: guardian-dev <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on behalf of Hans-Christoph Steiner <hans at guardianproject.info>
Sent: Thursday, April 16, 2015 12:26 PM
To: guardian-dev at lists.mayfirst.org
Subject: Re: [guardian-dev] zerobin as possible temp store for ChatSecure iOS

Sounds like Nathan understood you much better than I.  A "no sign up"
experience is very much within reach.  We already have it in the "Secret
Identity" function in ChatSecure-Android.  The hard part then is getting the
contact info around to the people that need it.  Since the point of the
"Secret Identity" is to keep that account limited to a very small number of
contacts, that is not hard problem.

The idea is that you set up a secret identity for each contact that needs very
private messaging, and pair it only with the other person's matching secret
identity.  This removes metadata leaks then because the network observer can
only see two accounts talking to each other.  With Tor and no social graph
info, it becomes extremely difficult to deanonymize.

This is how Laura Poitras and Edward Snowden communicated, albeit using email
accounts, but perhaps also XMPP accounts.

.hc

Yaron Goland:
> I think we all agree that our common goal is to reach a "no sign up" experience (which I now realize is a much better way to put this than Tor Like).
>
> The mocks show what I believe to be the minimal possible sign up experience given the current state of hosting services.
>
> But I think we all dream of a true "no sign up" experience. Imagine, as you suggest below, XMPP servers being hosted by volunteers where one can create an account in a completely automated fashion. We can easily create a HTTP interface that would let iOS download queued messages in the background.
>
> But one step at a time.
>
> BTW, on a completely unrelated note, I thought you would find http://www.softwarenerd.org/code/2015/4/16/bubble-chat-and-tsnpeerbluetooth-cocoapod interesting. Brian Lambert, one of the devs I work with on Thali, has released a library that gets BLE working about as well as one can hope for on iOS. He should post a link to it on the Thali blog soon.
>
>     Thanks,
>
>             Yaron
>
> ________________________________________
> From: guardian-dev <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on behalf of Nathan of Guardian <nathan at guardianproject.info>
> Sent: Thursday, April 16, 2015 10:28 AM
> To: guardian-dev at lists.mayfirst.org
> Subject: Re: [guardian-dev] zerobin as possible temp store for ChatSecure iOS
>
> On Thu, Apr 16, 2015, at 12:06 PM, Yaron Goland wrote:
>> What I really mean is are we going to have an email like experience or a
>> Tor like experience?
>>
>> Email - The user has to pick an email provider, establish a relationship
>> with them and then they can get email (even for free, of course nothing
>> is more expensive (in terms of privacy at least) than "free").
>>
>> Tor - Turn on Tor Onion Proxy - GO! No relationship. No exchange of funds
>> (although I happily donate each year!). Just go.
>>
>> I don't know what I don't know so I'm asking if the infrastructure exists
>> to provide a Tor like experience with XMPP/Zerobin or if it's more of an
>> Email like experience.
>
> It is actually a bit of a hybrid solution we are thinking of from the
> user experience side of things. We have a new onboarding experience that
> you can check out here:
> https://dev.guardianproject.info/boards/20/topics/264 and a big aspect
> of it is the "We're finding a place on the internet for you" step.
>
> The user only needs to enter a username they desire, and we'll go out
> and try to connect through a list of XMPP providers who fit our
> requirements for security and privacy, and setup an account for you
> automagically. We may offer you some basic preference of what @domain
> you want, in the way that say Fastmail or Hushmail do, but mostly you
> can just be *you* and happen to be at some domain, that mostly you don't
> have to worry about.
>
> The work that Hans mentioned we are doing, establishing a standard
> secure/privacy-by-default stack for XMPP and other services, is part of
> how we will grow that list of "places on the internet" we trust. Much
> like Tor, we want a broad network of global volunteers to run these
> instances, so that there is no single point of failure or risk.
>
> Again, if you check out our new onboarding experience, it really is much
> more of a "Go!" interaction, then a "and now you have to setup an
> acccount so please fill out these forms!" one.
>
> +n
>
>
>>
>> Does my query at least make sense?
>>
>>     Thanks,
>>
>>             Yaron
>>
>> ________________________________________
>> From: Hans-Christoph Steiner <hans at guardianproject.info>
>> Sent: Wednesday, April 15, 2015 4:23 PM
>> To: Yaron Goland; Michael Rogers
>> Cc: guardian-dev at lists.mayfirst.org >> guardian-dev
>> Subject: Re: [guardian-dev] zerobin as possible temp store for ChatSecure
>> iOS
>>
>> We're working to make a standard XMPP server platform that is built from
>> the
>> ground up for the best privacy.  otr.im and jabber.calyxinstitute.org are
>> two
>> good examples. So for that standard, something like this zerobin setup
>> would
>> be included.  It would be good to also have options when your XMPP server
>> does
>> not include a zerobin.
>>
>> I really hope we don't have to expect that users will set them up
>> themselves.
>>
>> .hc
>>
>> Yaron Goland:
>>> The key issue I'm trying to understand is if the expectation is that one can use existing XMPP and ZeroBin providers to enable iOS users to do background downloads over HTTPS. Or is this a situation where users are expected to set up and run their own servers?
>>>     Thanks,
>>>         Yaron
>>>
>>> ________________________________________
>>> From: guardian-dev <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on behalf of Michael Rogers <michael at briarproject.org>
>>> Sent: Monday, April 13, 2015 1:21 AM
>>> To: Hans of Guardian
>>> Cc: guardian-dev at lists.mayfirst.org >> guardian-dev
>>> Subject: Re: [guardian-dev] zerobin as possible temp store for ChatSecure iOS
>>>
>>> On 13/04/15 03:59, Hans of Guardian wrote:
>>>>>> We do have to work out how to protect some of the details, and figure out how
>>>>>> to integrate with various push services like Apple or Google GCM.  Here's an
>>>>>> attempt to flush some of that out, based on your outline:
>>>>>>
>>>>>> * Phone1 encrypts content with OTR Extra Symmetric Key
>>>>>
>>>>> Phone1 could use a fresh key here in order to avoid potentially
>>>>> encrypting more than one file with the same key.
>>>>
>>>> As far as I understand it the OTR TLV8 Extra Symmetric Key is generated per session, but I could be wrong.  It has the big advantage of both sides being able to generate it without actually sending it to each other.
>>>
>>> But there's only one key per session, right? What happens if you send
>>> more than one file in a session?
>>>
>>>>> How much work is the push message handler allowed to do? Can you, for
>>>>> example, maintain a separate OTR session for push messages?
>>>>
>>>> Hmm, interesting idea.  I think that the timeframe might be too slow for OTR, but maybe there could be an axolotl session via the push framework.  That sounds a lot more complicated to implement though.  TextSecure uses GCM to do all of the message sending, so it should be possible.  I don't know about Apple's push though.
>>>
>>> Does OTR have time limits? The only reference I can see to time in the
>>> OTRv3 spec is the configurable time between heartbeat messages. It looks
>>> like that could be made arbitrarily long if the implementation allows.
>>>
>>> On the other hand, OTR requires in-order delivery - I don't know whether
>>> push messages guarantee that.
>>>
>>> Cheers,
>>> Michael
>>>
>>
>> --
>> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
>> _______________________________________________
>> 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/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>

--
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
_______________________________________________
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org


More information about the guardian-dev mailing list