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 > <[email protected]> on behalf of > Nathan of Guardian <[email protected]> > Sent: Thursday, April 16, 2015 10:28 AM > To: [email protected] > 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 <[email protected]> >> Sent: Wednesday, April 15, 2015 4:23 PM >> To: Yaron Goland; Michael Rogers >> Cc: [email protected] >> 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 >>> <[email protected]> on behalf of >>> Michael Rogers <[email protected]> >>> Sent: Monday, April 13, 2015 1:21 AM >>> To: Hans of Guardian >>> Cc: [email protected] >> 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: [email protected] > > > -- > Nathan of Guardian > [email protected] > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] > -- 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: [email protected]
