[guardian-dev] zerobin as possible temp store for ChatSecure iOS
Yaron Goland
yarong at microsoft.com
Thu Apr 16 13:59:48 EDT 2015
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
More information about the guardian-dev
mailing list