But like I mentioned in the article I am using this to replace a closed source cloud solution I was previously using so it is a step in the right direction.
1) Reverse-engineering isn't clean and can be circumvented.
2) BTsync has not reached a point where it can't be beaten by a competing protocol.
I am writing a similar project which is fairly immature: https://github.com/cryptosphere/cryptosphere
Between that and a "compare timestamps to figure out the newest file" I wouldn't think it would be that hard to re-create? What am I missing here?
I assume the sync protocol works the same. It hashes the file, checks if any chunks have changed, sends the hash meta-data to the recipient, who then requests and pieces that have changed.
If the protocol is published properly you won't have to: people will write their own free software implementations.
Just kidding. Partly.
Kind of like tarsnap or Tahoe-LAFS, but auto-syncing, etc like Dropbox.
The first open source project to give me Dropbox-like ease of use/functionality with strong encryption will win my support.
(Accidentally replied to the wrong parent.)
I'm not clear what there is to stop someone iterating through all combinations (especially as many will use dictionary-based secrets) to discover shares. Additionally, the master server BitTorrent run to broker the connections presumably also has all of the shared secrets and is vulnerable to attack.
I'm really excited about BTSync and have been proud to be in the early beta program but these security issues don't appear to be addressed.
Also, if someone did have the master list of hashed secrets, they might still be able to manipulate their own client to send the hashed secret back to the server and gain access.
Being closed source, it's hard to know what the potential vectors are (granted, Dropbox is also closed source).
so can you clarify what you're worried about?
The author really should have a backup plan in place. He still doesn't, even though this software lets him sleep easy at night. He's still riding the edge of disaster if a file ever becomes corrupted and then synced. Ut oh. Incremental backups, folks. It's really not that hard.
On the open source side of things, Dropbox and BT Sync aren't really that interesting. You could whip up similar functionality with a bash script, inotify, and rsync in a matter of hours. Dropbox is only relevant because they give you off-site always online dumb storage. There will never be an open source or "trustworthy" solution to a cloud storage service. This Raspberry Pi idea is pretty neat, though. But local encryption is always the answer.
Also, if you have important data that should be encrypted, then it's a pretty stupid thing to have it synced all over the place. You don't want every device acting as a possible point of compromise. Principle of least privilege, and all that.
a) You didn't read the article.
b) Tinkering with technology to do fun things is of no interest to you.
I think the author really just wanted an excuse to use his Raspberry Pi.
I do love to tinker. But I don't do foolish things like replace backups with fragile dogshit.
BTSync also does built in versioning which solves the backup issue.
So for example, if a person was working on a thesis document and then accidentally overwrote that with a blank version which gets synced across all the nodes, it would be possible to reverse this action and recover the original thesis document ?
Of course running a cronjob on your raspberry pi to do incremental backups would be a fun way of tackling that problem.
I write code on several computers and I use Dropbox to keep the files in sync so that I am able to quickly resume working when switching computers. I've never had any kind of sync problems with Dropbox.
I tried doing the same with BT Sync. The biggest problem I had was that sometimes it didn't sync all files. Say I had a directory with 10 files and 3 computers in the BT Sync "network". It was not unusual that 8 files got synced between all computers but 2 of the files would never get synced to one of the computers. Then at a later time, randomly, it would resume sync-ing. After having this problem 3 or 4 times I went back to using Dropbox and never looked back.
Perhaps we could use git-annex for this?
With BTSync, I can sync hundreds of gigabytes over a LAN with very little effort. I do hope a good open source option will be available soon, but for many use cases this is a big upgrade.
While I'm away from home I use a usb-stick with a custom dev envrionment all set up. Then just backup and fetch files from there as needed. Something like this gets the job done:
rsync -avze ssh ~/my/backupfile user@(home ip address):~/backup/location
Probably a bit weird to understand but this is just one example command for backing up a local file (there are more advanced options too).
The client portion runs on pretty much anything remotely modern.
I have no pi so I can't say how well it actually runs.
The whole single string security is a mixed blessing... It is what makes the application so easy, and at the same time, it makes it feel so insecure!
Edit: I stand corrected, BTSync apparently now has a previous version feature.
edit: here's what i purchased:
 CanaKit Raspberry Pi (512 MB) Complete Starter Kit (Raspberry Pi 512 MB + Black Case + Micro USB Power Supply + Original Preloaded SD Card + HDMI Cable)
 Edimax EW-7811Un 150 Mbps Wireless 11n Nano Size USB Adapter with EZmax Setup Wizard
 SanDisk Cruzer Fit CZ33 32GB USB Flash Drive (SDCZ33-032G-B35)
 Preloaded SD Card for Raspberry Pi (16GB, Raspbian "wheezy")
* Raspberry Pi
* SD Card with OS (Raspbian Wheezy is the simplest to use)
* USB power cable
* Internet connection (Ethernet cable or USB WiFi dongle)
The rest is software that is described in my article.
You can now have your own free 30gb git repo as well.
Words of caution:
- Buy a second SD card ;
- once you have a running rPi tweaked to your liking clone it with dd to prevent eventual data loss.
I wasn't clear: the second SD card is to play with more than one OS or to be able to quickly swap a working distro in case the first one goes wrong (dd to a file is of course the mandatory way to go but having the second SD card plug-and-play is more convenient IMO:no fdisk involved).
also, on the topic of internet connection, at least the contracts i've seen (AT&T, Verizon) you can't have any 'server' or accept any connection initiated from the outside in your home account. As crazy as it may seems, this is on the contract you probably signed to have internet.
It supports zipping/unzipping, file preview, editing, sharing and many other things.
And best of all - it's open source and you can create custom plugins for it.
but then again, having dropbox just work is pretty swell too.