ChrisH

Members
  • Posts

    247
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by ChrisH

  1. Then it wouldn't be P2P anymore. It's as simple as that.
  2. It has already been "addressed" - in that it used to work in earlier versions on the BTSync App and they removed it on purpose. Why? No idea.
  3. With "quicker" I meant the effort for the user to setup the sync, not the sync itself. And using existing GUI options seems less effort to me than messing around with zip files and hex editors. YMMV.
  4. That's not really quicker than "my" way, is it?
  5. I know, that's why I linked to one of them
  6. No, that's currently something only the Android (and iOS?) app does. See http://forum.bittorrent.com/topic/30010-none-deleting-node/ for an existing more general requirement.
  7. +1. Although I don't like custom right-click context menus in web applications, it would feel more native here.
  8. Also, see http://forum.bittorrent.com/topic/30034-remote-delete/ for some other arguments against
  9. Because it is a backup, not a read only sync. Sure, but it's a little complicated because they oversimplified the latest app version (AGAIN) so people who know what they are doing have to work harder to get there. Because creating keys on the phone was too confusing or something. 1. Create a new shared folder on the PC 2. Connect the phone to the folder by scanning the r/w QR code 3. Copy the r/o key from the PC 4. Change the key on the PC to the r/o key (depending on your BTSync version it may be necessary to remove and re-add the folder)
  10. The problem is not getting BTSync to run in the background, but accessing the GUI while it does.
  11. The key word is "easier". Not "effortless". And it definitely is easier than building fat clients for every major OS (which probably is why they didn't bother to try with anything but Windows in the first place). For me it's not the GUI in itself so much, it is the mindset behind it. And I don't blame the developers, I blame (product) managers - until proven otherwise. I definitely will switch to SyncThing/Pulse as soon as it has all the features I need, unless BTSync does a radical change (like going open source and/or really letting the users decide what features to concentrate on).
  12. What? Who thought that would be a good idea? Surely the principle should be to skip handling a file as soon as possible if it is to be ignored anyway. So why open it at all?
  13. Ah, ok. It sounded like you had everything only on your PC and synced that somewhere, so I thought a NAS that runs all the time and does the syncing could relieve your PC from that. Off-topic and just wondering, because you probably know what you are doing: You really need to access ALL your RAW photos ALL the time? Maybe there could be an option to skip the startup indexing and just re-use the last known index? It should come with a big honking "I KNOW I CAN SHOOT MYSELF IN THE FOOT WITH THIS" warning dialog, but for users that can guarantee to have BTSync running all the time and not to change any files while it is not, re-indexing on every start is just a waste of time and resources.
  14. So as of now we have three use cases: 1. You lose your device by accident and someone finds it. Solution: Use disk encryption. 2. Someone invests criminal energy to steal your device. Solution: Use disk encryption with two-factor authentication. Remote wipe won't work because a criminal will know how to circumvent it (copy hard disk, start device offline). 3. Someone is using your data legitimately and you want it back at some point. There is no reliable technical solution for that.
  15. If you sync files that are encrypted individually and if you open them on your PC first an decryption programs starts up, those files will also be encrypted on your sync partners. Those mostly will have an additional file extension (e.g. in AxCrypt's case: My Document.docx.axx). If you sync files that are encrypted transparently (TrueCrypt, Windows EFS) BTSync reads and syncs them in clear text (unless the sync partner has an encrypted-read-only secret instead of the normal r/w or r/o ones). So you would have to sync the whole encrypted container (e.g. for TrueCrypt: the .tc file) instead of the individual files.
  16. Okay. So how does a remote wipe function for one program protect against social engineering? Either I provided the device for my employee, then it gets returned (no need for remote wipe), or it's his own device, then he surely would not want somebody deleting data at will on his device. And he may have already copied "my" data somewhere else. And in both cases you have to change the BTSync key anyway, which is a problem that should be solved first, before we consider things like remote wipe/encrypt capabilities.
  17. As long as it's understood that "your" feature will only work against very stupid thieves, fine. BTW, how did you manage to lose your device and your disk encryption password at the same time?
  18. And "full remote control" does not help against thieves who are clever enough to copy the harddisk first or start the device offline. Now what?
  19. No, you want to secure ALL your data. Not only those folders synced with BTSync and not only if the device happens to be online somewhen. Use some sort of full disk encryption (Bitlocker, TrueCrypt, whatever) and stop worrying about data in single apps.
  20. Yes, they are compatible (for now). http://syncapp.bittorrent.com/1.3.109/
  21. Well yes, if you can just move folders around at will, putting them all under one parent folder and syncing that will work. If you can't, it won't. I have the same problem on Android where I would like to sync several folders (some on internal storage, some on sd cards) per device with one central BTSync backup server. At the moment I have to have share each folder separately and with its own secret, which means the folder list on the server gets pretty crowded. Anyone tried to use symlinks/hardlinks/whatever for that?