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

Hans-Christoph Steiner hans at at.or.at
Sun Apr 12 22:39:05 EDT 2015


On Apr 11, 2015, at 5:39 AM, Tom Ritter wrote:

> On 9 April 2015 at 10:09, Hans-Christoph Steiner <hans at at.or.at> wrote:
>> Feedback welcome, I think this could help with iOS usability a lot without
>> leaking much extra information. I think it could also help make transferring
>> large files with ChatSecure on Android more usable as well.
> 
> As I understand it:
> 
> Alice and Bob on the same XMPP Provider AB will use a zerobin instance
> run by Provider AB. No additional metadata leaks.

The network observer would be able to see some metadata.  They would be able to see that Alice is transferring a file to zerobin, and see the size of that file.  Or they could see that Bob is receiving a file, and see the size of that file.  For this reason, I think it would be a good to include padding to round off the file size to reduce the possibility of correlating transfers with known files based on size.


> Alice and Bob on separate XMPP Providers A and B will use a zerobin
> instance run by either Provider A or B. A or B will then learn the
> public IP of Bob or Alice which is new information.  You could say
> that the initiator of the file transfer will use the provider of the
> recipient to be "gracious", and leak their own IP instead of
> requesting the recipient to leak theirs.
> 
> And if Alice or Bob use an XMPP provider that does not run a zerobin
> instance (like google) they will leak their public IP to the provider
> that they do use.
> 
> So it seems the priority of choice for the instance to use would be:
> - Zerobin Instance run by Provider of recipient
> - Zerobin Instance run by Provider of sender (if the recipient's
> provider doesn't run one)
> - Zerobin Instance run by a trusted third party (if no one's provider runs one)

I'm thinking more the guiding principle is that expect iOS to use direct connections while other platforms use Tor when transferring files via the zerobin.  So in that case, each client would then post to the zerobin of their own XMPP server, then expect the receiver to use Tor if they need to reduce metadata leakage.  iOS users can download via Tor also, but only in the foreground, not as a background process.

Perhaps this order should change based on whether the sender is using Tor or not.  If the sender is using a direct connection, then the order is:

- sender's provider's Zerobin
- receiver's provider's Zerobin (if the sender's provider doesn't run one)
- Zerobin Instance run by a trusted third party (if no one's provider runs one)

If sending via Tor, then it would be the order you first specified:
- receiver's provider's Zerobin
- sender's provider's Zerobin (if the recipient's provider doesn't run one)
- Zerobin Instance run by a trusted third party (if no one's provider runs one)


> I don't imagine you have stats on the popularity of XMPP providers for
> ChatSecure?

We don't have many stats since we don't add any tracking to ChatSecure besides hockeyapp for crash reports. My guess is that Google is the most used XMPP account with ChatSecure.


> Also: I would audit zerobin and ensure there is no metadata that can
> leak via public crawling (such as number of transfers occurring,
> publicly indexable lists of files (although the "burn after
> downloading" seems to address that a bit.))  This is no different than
> the security of XMPP servers leaking information though via
> misconfiguration (such as chat rooms or logs being accidently left
> laying around.)
> 
> -tom

Definitely a good idea.

.hc





More information about the guardian-dev mailing list