ChrisH

Every OS now has a built-in firewall for filtering incoming connections. A MAC filter only works on the local LAN - if you don't trust the users and machines there you have a bigger problem. What's your use case for additional filters in BTSync itself? Why would you want to disable the read only secret?

How do you authenticate a user? How do you distribute the access control lists? How do you control who can change them? How do you make sure every BTSync client does this user authentication and honors the ACLs?

I think most of the security concerns about BTSync (apart from it not being open source) could be addressed with a little better control over peer devices, especially new ones. 1. You should be able to set folder options the first time you create the folder. As it is now, you have to create the folder first, it is created will all the default options (which means the BTSync tracker knows the secret) and then you can switch to known devices or LAN sync only. 2. As an per-folder-option, you should choose whether you have to approve new peer devices accessing that folder. This is not perfect because device names can be spoofed and you have no control over what happens at other nodes, but it is a first step. Later there could be fingerprints or something, if needed. 3. The "known" peer devices for a folder (i.e. all devices that have ever synced something) should be recorded and displayed in the GUI somewhere. Maybe the type of secret the device used (RW, RO, ERO) could also be displayed. These are all GUI requirements and can be done without changes to the protocol. Nice-to-have but requiring a protocol change would be: 4. The known peer devices from #3 are distributed to other nodes as part of the share. So each device knows every other device that has ever accessed the share. This would be great for distributing networks.

Or you could just name your photos and videos with meaningful file names But I agree, selective sync has still a long way to go.

I still prefer wiping devices with a text message or push command instead of reimplementing that functionality within BTSync with all the things that can go wrong with it (security, as you mentioned; the device has to have an internet connection; BTSync has to be running; a BTSync node has to be up and reachable; what about canceling the wipe command because you find the device in your bag after all; etc. etc.)

Aren't there already enough apps and services out there that allow you to wipe your device remotely? Why do you need another way to just delete BTSync data? I mean if your device gets stolen you'd want to wipe ALL data on it, not just the stuff that BTSync knows about.

True. But related (please split into separate thread if you wish): It would be nice to have BTSync URLs pointing to a single file, like btsync://A1234ABCDDEADBEEF/folder/file.jpg. Of course that would only work if BTSync was already installed, but it could download a single file from the share given and ask the user where to put it. After the download is complete, the share would be removed automatically.

You still would have to reimplement the current protocol in HTTP. That IS a massive overhaul, regardless whether you keep the old stuff or replace it. The work is the same.

So the old wishlist thread did get too confusing after all, eh? I would like to have the option to run BTSync as a Windows service. I personally would be okay with sacrificing the Windows GUI for that and using a Web GUI like the Linux versions do. My use case: Headless Windows Home Servers that no-one logs in to. There are workarounds right now, but they all have in common that I have to kill the task or service, start BTSync interactively, make the configuration changes I need, shutdown BTSync and start the task or service again.

If all you need is 10 G, I recommend buying a mobile phone and installing BTSync on it.

If you only have 2-3 machines then just use "known hosts" and disable the tracker server. That way an attacker would need to guess both your secret and your hostname/IP (and the port number, but a portscan will reveal that easily). I agree your proposal would be nice to have, but to get it right and secure this needs to be thought through thoroughly - and I am pretty sure that will mean changes to the design of BTSync. There is enough on the todo list that can be solved without fundamental changes, so it should be done first.

I know. But not in the Android app when backing up a folder (I guess iOS has the same issue), which is what the OP was talking about. How many characters does your email password have? Your "certificate switch" idea only works if there is one master device controlling access to the share (and that has to be always under your control). BTSync is not limited to that type of setup.

I agree that having to use the secret that a closed source app provides you is dubious at best. The other points were already discussed at length. In short: If you add the username you just have to guess e.g. 40 characters instead of 33 - that's only a difference in quantity, not in quality and thus not "super strong". You already have to get all the bits right, regardless of whether they are in one or two fields. I also would like to have the option to confirm new nodes on first contact, but then you would have to have an authentication system for the nodes (because otherwise anyone could name his node "Chris Laptop") and the nodes would have to synchronise their confirmations somehow - in other words, it would require changes to the design and the protocol.

ASP will not help you, because the code will then still run on the server, not the client. Something like a Java applet might work, but the user probably would have to acknowledge lots of warning messages because the applet has to access both the network and local files. Besides, who has Java still installed by default these days? It might be possible to create a ClickOnce-Wrapper or something around btsync in order to ease the download/installation process, but you would still have to enter the secret and select the local sync folder. Maybe an AutoIt-File that does the download, installation and configuration might be worth looking into? Then your users just would have to click on a link to the compliled Autoit-Exe and all the other steps would be done automatically.

+1 for plain text config files at least.

Network usage can already be controlled in preferences. CPU load should not be a problem on moderately decent hardware. But I agree (again) that the interface must be separated from the background worker in order to run as a service or task. At the moment I let it run as a task that runs on system start and just kill it via the task manager and start it manually again if I want to change some settings. Linux version already has a web interface, why not use that?

Not a good idea. It probably will regard all files as deleted on reboot and delete them from all other nodes as well.

Yeah, great idea. Let's all have someone else generate our keys and get them to us via an unencrypted channel. It's not like there's anyone monitoring the internet or something.

Really.

I don't get it either. The wishlist thread as it is now is useless.

Try it out, but I'm guessing BTSync won't even open the files as long as at least one Access instance is running.

I agree it only looks like BTSync transfers the whole file, when it actually compares chunk checksums and transfers only the differences. But be aware that BTSync will not compare file dates to establish who has the newest version of a file - it compares the "file added to BTSync" timestamps instead. So you could end up overwriting new with old versions.

Still on workarounds as of now.

I think parsing individual file formats would be a lot of work for very little overall gain. I'd rather see moved block detection in the sync algorithm so all file formats can profit from the improvement.

Are you trying to sync an Exchange Mailbox database? That won't work as long as Exchange is running and has locked the files.