What we are describing would be an email experience, since we need to have ways of doing standard HTTP transfers to support iOS's background operation. I can't see you a way to do the Tor-like experience and still support iOS's background.
But using Tor Hidden Services, it would be possible to run the zerobin on any device to provide a Tor-like experience, where the zerobin is part of the client software. .hc Yaron Goland: > 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. > > 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 > -- 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]
