ChrisH

Members
  • Content Count

    247
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by ChrisH

  1. Then maybe BTSync just isn't the optimal solution for your requirements and you would be better off with a traditional system that uses distinct credentials like username and password specific to each user. Anything slapped onto BTSync with its peer-to-peer design will just be a makeshift solution, not an inherently secure one.
  2. I know, but asking for a feature that only works for your (pretty specific) use case is a bit short-sighted, don't you think?
  3. It would also need some history function to show the last reported space even if the device is not connected right now. If I have to start / wake up BTSync manually on my phone so I can see the available space info in my desktop's BTSync, I can just look on the phone myself.
  4. As soon as you share a folder with someone, you lose control over the contents anyway. Even with your idea of communication codes, you cannot stop them from just creating a new BTSync share (with a secret THEY control) with your data in it. Or posting it to Facebook or whatever. You are looking for a technical solution to a social problem. If you don't want someone to give away your data or your secret, tell them. If you don't trust them, don't give them your data. It's as simple as that.
  5. So... your idea is just a workaround so you don't have to create folder two on the server yourself? Seems a bit involved to me, and it doesn't really have anything to do with the original proposal in this thread.
  6. (1) no idea (2) last change wins (3) depends on your configuration - you can have circle, star or full-mesh setups
  7. I like the idea, but it needs more security than just the device name (which could easily be brute forced and then existing files could be overwritten). I would also like to see some sort of quota to restrict the upload size per device.
  8. The "problem" in the current design is that there is no single machine A. There are (potentially) lots of As and they are all equal. If you have only one A, simply re-create the folder with a new secret. (Yes, you have to send the new secret to all other Bs that shall continue to have access.) I unterstand your requirement, but as I see it that would mean a major change in BTSync's design. You would have to introduce a central instance or control server. I would like to have that as well, but like I said, that might be something for the business version.
  9. That works in Dropbox because the Dropbox servers are the central instance. This differs conceptually from the way BTSync is designed. There is no "master" that could control access or distribute new keys. Maybe the long-promised "pro / business" version of BTSync contains something like that.
  10. Yeah. Encrypted data does not compress well (or at all).
  11. I use BTSync only over tinc connections with compression already in place, but +1 from me anyway. Since the transfer is already chunk-based it should be trivial to compress the chunk before sending it and decompress it before writing it to disk.
  12. You could just create an upload folder on your server with identical structure as your normal work folders. Share that via BTSync and let a script run regularly (or on an "upload complete" event triggered by BTSync API) on the server that moves all new files from the upload structure to the work structure. As soon as that is done, BTSync will delete the file from the client's upload folder. You still won't have access to your existing files while offline, so I'm not sure if that idea covers your requirements.
  13. What's the advantage of NSSM over just running BTSync as a scheduled task? You still have no access to the GUI because BTSync on Windows was not designed to run as a background process.
  14. I think for that you'd need some kind of master node with a separate "upload" share. Any member can put files in the upload share, and the master node moves those files into the main share (that is readonly for everyone else).
  15. I think the way to do that is take an already working VPN solution (like tinc, maybe) and add some sort of tracker server and NAT hole punching functionality to it. Developing the VPN part seems to be more complicated and error-prone to me than the tracker part BTSync already has.
  16. I think there are enough remote control solutions (personally I use Teamviewer) that work without the need for port forwarding. I think your request would be more in the scope of a bigger Mesh-replacement application that integrates both RDP and BTSync functionality. Maybe Hamachi and BTSync might make a good combination for your purposes?
  17. What's the difference between two secrets consisting of 128 bits each, and one secret consisting of 256 bits? You still have to guess all the bits. And whether you have to change the pre-shared key or the secret on all non-outdated nodes does not make any difference, does it?
  18. I would never use BTSync or any other distribution system without per-user-access control for that scenario. If you have to use BTSync, use it in the internal LAN or over a VPN with additional user authentication only. What happens if the employee just stops or blocks BTSyncControl so the wipe command never gets there? How do you make sure the secret change command (you did not describe that, but you'd need one, right?) reaches all nodes? How do you stop employees from creating their own shares without them using the control mechanism?
  19. +1, see also http://forum.bittorrent.com/topic/29659-btsync-as-a-windows-service/
  20. So simply set up one shared folder per client. And for true backup functionality remember to set sync_trash_ttl to 0 - otherwise deleted files and old versions will disappear from the backup copy.
  21. 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?
  22. 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?
  23. 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
  24. 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.