A Closer Look at BitTorrent's SyncApp

A few hours after publishing my previous blog article on p2p File Sharing - a Dropbox Killer?, I was very proactively contacted by Kos Lissounov, in charge of development for BitTorrent Sync.  I received a SyncApp tester invite and was able to test-run the product on three devices in a sync group (2x OS X, 1x Windows 7).  Kos and I also had a good and professional back-and-forth of emails and he provided thoughtful answers and comments.  It wasn't my intent to dive down the rabbit hole with SyncApp and BitTorrent security models, but some hours later...

I'm pleased to say that the "pre-alpha" version of BitTorrent SyncApp worked fine for it's main purpose at this point - quickly move around lots of files and data between a specific group of devices.  In particular, bringing a third device into the share group (all on same LAN and nicely linked together - no need to hit the cloud to download files) during my tests ran even faster with two sources of data available to bring the third device into sync.

However, to clarify the key assumption I had when writing the p2p File Sharing - a Dropbox Killer? article:  Can p2p sync replace my day-to-day use of Dropbox, but with unlimited data and at much less cost or for free?  Implicit in that assumption were all the usual points of comparison in the back of my mind: features (vs Dropbox), Just Works (stable), cheaper (for big data sets under sync), faster, more reliable, better usability, more secure, etc.

Based on this, here are a few additional comments about Bit Torrent SyncApp:

1. Empty folders are not synced.  Per Kos, this deficit is recognised and will be added.
2. Version conflicts are simply ignored.  However, rather than warning or in any way indicating a conflict, the client just silently ignores the conflicted file.  Version conflict management is apparently tough to implement.  I don't think any type of merge function is required, but I do think a visual warning and changing file names to highlight the conflict is.  Just imagine the issues trying to unpick file conflicts inside of BoxCryptor's "Package" folder with silent failure and removal of a single file from synchronisation...
3. Their is no API yet.  One could imagine an app simply accessing SyncApp folders via the filesystem on bigger devices (no API required) and using a secret to access a set of folders/files on a mobile device via an API.
4. Usability is generally a big deficit.  Features like iconic representation of sync state (as done by Dropbox) in a Finder and File Explorer window aren't present.
5. A "relay" server is required to connect devices via shared "secrets" if the devices are not on the same network and if the peers haven't otherwise previously communicated with each other.  Of course, if one device is a phone or laptop with regularly changing network parameters (on the move between networks), the relay will have to be used to link up the devices.

Items 1 and 2 above for me are showstoppers if my use case is to replace Dropbox with SyncApp.  Items 3 and 4 are painful, but might be tolerated for awhile.  Item 5's relays and "secrets" is tricky to judge because I don't fully understand the security implications.  Let's drill into relays and secrets a bit more.

Relays are a key enabler of the BitTorrent SyncApp approach.  They perform the following functions:

1. Recommend (not approve if I understand the protocol correctly) the sync of a folder/file set between devices by seeing identical encrypted secrets and recommending the two devices sync with each other.  The two devices must still directly authenticate each other (without the relay involved) - the specifics of this authentication are unknown to me.
2. Facilitate/broker communication between devices that can't otherwise discover or communicate with each other that have the same secret - deal with firewall issues just as BitTorrent clients do today.
3. Relay (SHA256 encrypted) information between two devices if the two devices can't otherwise send information between each each other.

Relays do not see any unencrypted data.  They do see and manage SHA256 encrypted "secrets".  Relays store all their information in memory, nothing is persisted to disk.  If the relay goes down then the secret relationship between devices may have to be rebuilt (depends on the device to device access and what specific functions the relay was required for in a given setup).

The concept of the shared "secret" is interesting.  It is a way to enable devices to join in a group to share content.  It has a similar feel to a Bluetooth PIN that is asserted by one device and entered by the other to allow communications between them.  Each folder (and subordinate folders and files) has a unique secret.  Relays (for now a public/shared one run by BitTorrent) are used to coordinate devices with the same secret that can't otherwise find and/or communicate with each other.

I can see two security holes with the "secret" approach:

1. A secret could be sniffed from the wire and used by a malicious SyncApp client to attempt to join a group of devices with the same secret.
2. The relay manager (for now the BitTorrent company) could manually insert malicious devices into the relay's device management system.

Kos clarified that the secret is encoded via SHA256(SHA256(secret) - therefore the password (or "secret") is stretched but not salted.  Also that it would be possible to get a list of peers but in order to join a sync group you would have to decrypt the AES256 handshake with the peer with the key SHA256(secret).  Again, I don't know the details of the protocol that engages between the two devices to actually approve joining a sync group so actual joining may be blocked.

Regardless, I remain uncomfortable with the security provided by the "secret" approach as it is today without fully understanding the protocol and implications.  This is also a showstopper for me with respect to using SyncApp to replace Dropbox at least for sensitive information.

Kos indicated a "Should device X be allowed to join this group?" a challenge will be added to SyncApp in the future to help address security concerns.  People/companies can also run their own relays meaning that they can control everything for their sync groups.  However, I think without a central service (relay or otherwise) to provide authentication and authorisation for users, devices, and secrets the product will remain limited from a usability and security perspective.  The Bit Torrent company's obsession with fully distributed, no-master, p2p approaches may really limit long-term market acceptance due to usability and security limitations.  I believe it will also limit their ability to see product adoption beyond a technical community (in which it may excel, just as it has with BitTorrent itself) and in turn be unable to monitize the product.  Even if BitTorrent did put in a central auth server (and even nominally charge for it to make money), would it be trusted given their brand position?  This is where products and companies like Cubby and Skype may have an advantage.

Even more than before, after this review of BitSync I think services like Dropbox, Box.Net, and Skydrive will struggle to compete with p2p sync as their whole business model is tied up in users consuming and paying for cloud disk space.

One use case for which BitTorrent SyncApp excels today is for a fairly technical user to simply keep a group of media files in sync, for example a photo archive on your laptop while you're on vacation being synced (automatically backed up when you have an Internet connection) to a PC running at home.    None of the above issues hold back adoption of SyncApp today for this use case.  In fact, switching to SyncApp for bulk media and other big files (e.g., install images, video, audio) and using Dropbox just for docs and simple workgroup collaboration is a good possibility for me once I'm comfortable SyncApp is sufficiently stable and Just Works.  Of course, even if SyncApp or another similar p2p product closes the feature gap with Dropbox, I still couldn't eliminate Dropbox completely because their first mover advantage is incredible and they are really bedded into the Way the Internet Works now.

If SyncApp can get past their "must be p2p only with no central auth server and keep track of nothing" view of the world and add in some of the features I've covered in this entry, I think it could become a viable Dropbox killer and be meaningful part of a "post cloud" Internet world.