hypercat

Members
  • Content Count

    12
  • Joined

  • Last visited

  • Days Won

    1

About hypercat

  • Rank
    Member

Profile Information

  • Gender
    Male

Contact Methods

  • Yahoo
    hypercat@rocketmail.com
  1. Support for extended attribute syncing is not a deal killer for me during this Beta phase of BTSync. But support for extended attribute syncing will become crucial very soon.
  2. Support for extended attributes is essential for me for BTSync to become my primary sync tool. Please add support for extended attribute syncing!
  3. I would like to see the software changed so that temporary files are not stored in the synced folder. These temporary files cause other apps which are watching the synced folder(s) to process the temporary files. For example, I am trying to use Viivo to encrypt files before BTSync syncs them. This cannot be done because BTSync is creating temporary files with a .!sync extension which get processed by the Viivo app. Please create temporary files inside the Application Support folder or anywhere else besides the actual sync folder. Thank you!
  4. An alternative that I have been working on uses Viivo to encrypt the files destined for the Mac mini server and uses Bittorrent Sync to sync the Viivo-Encrypted folder to the Mac mini server. Viivo encrypts the file contents but not the file names. So it's less secure, but I can identify the specific file(s) I want to restore. Using Viivo I do not need to pause syncing on all peers. I can simply remove or pause syncing on the Mac mini server and restore the Viivo encrypted file using Crashplan. Then I can copy the restored Viivo encrypted file back to a local machine and use Viivo to decrypt the restored file on the local machine. It would be nice to see a function to decrypt files encrypted with the BTSync encryption secret added to the BTSync API.
  5. I am working on replacing Dropbox by syncing via an encrypted read-only secret to my collocated Mac mini server. The encrypted read-only secret keeps the files and filenames encrypted on the collocated Mac mini, protecting the synced data from rogue server admins. The sync folder on the Mac mini server is backed up using Crashplan. Crashplan also provides version histories for each file. So far, so good... The problem I am having is figuring out how to restore a file from the Mac mini server back to all of the synced folders. The only solution I have come up with so far is: 1.) pause syncing from all peers 2.) use Crashplan to restore the entire synced folder back to some previous date/state 3.) create a new read-only peer to receive the decrypted files from the Mac mini server 4.) copy the file(s) to be restored from the new read-only peer to one of the read-write peers 5.) remove the read-only peer used for the restore in step 3 6.) resume syncing on all peers This works but has several issues: 1.) the encrypted file names on the Mac mini server prevent me from seeing the exact file(s) I want to restore, so I am forced to restore all files back to the desired restore date 2.) this solution works only if I have access and control of all read-write peers since I must first pause syncing on all peers during the restore procedure Does anyone have an alternative solution? For those interested in testing this out, you can create an encrypted read-only secret without using the BTSync API as outlined in: http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key/ From the BTSync API docs: "The Encryption Secret is new functionality. This is a secret for a read-only peer with encrypted content (the peer can sync files but can not see their content). One example use is if a user wanted to backup files to an untrusted, unsecure, or public location. This is set to disabled by default for all users but included in the API." http://www.bittorrent.com/sync/developers/api
  6. Thanks to jtroth I am now using an encrypted read-only secret to sync to my collocated server. This not only keeps the contents of the files encrypted but also encrypts the file names as well. Awesome. And there is a way to generate the encrypted read-only secret without using the API calls: http://forum.bittorrent.com/topic/25823-generate-encrypted-read-only-secret-without-api-key/
  7. In response to InstagateurX's concern, is there currently a way to limit the size of a synced folder? For example, if my friend sends me a read only secret and I create a synced folder, and then my friend "accidentally" drops 2 TB of files into said folder. I would like to be able to stop that folder from eating up all my hard drive space and causing my machine to crash. Does this feature exist?
  8. Thanks to jtroth for pointing out that the BTSync API has an encryption secret that can be used to keep the synced files encrypted on a recipient's computer. From the BTSync API docs: "The Encryption Secret is new functionality. This is a secret for a read-only peer with encrypted content (the peer can sync files but can not see their content). One example use is if a user wanted to backup files to an untrusted, unsecure, or public location. This is set to disabled by default for all users but included in the API." http://www.bittorrent.com/sync/developers/api This solves the problem of syncing folders to a collocated server where one wants to keep the synced folders from being readable by collocation admins. I have been successful is using Viivo to implement this functionality by syncing the Viivo encrypted files to my collocated server. As long as I don't enable Viivo on the collocated server, the encrypted files remain synced without the .viivo.!sync file extension problem as described in my initial post above. I still would really like to see the ability of a 3rd party (non-BT) encryption tool to encrypt/decrypt files as well. For this to work BTSync needs to stop creating temporary files inside the synced folders.
  9. Filevault requires manual hands-on intervention in case of restarting after a power failure. So I am looking to use something like Viivo or some other file encryption tool to keep the data encrypted at rest on the server.
  10. Some people are already doing this: [link removed] The problem with the sync keys listed on the site above is that they generally are for folders which contain multiple files (movies, music, games, etc.) It would be much better to create one folder for each file so that the secret will sync only that file. Also, since the read-only secret allows the indexing site owner to see the decrypted file and thus have knowledge of it's copyright infringement, it would be best to distribute the sync key index/search site via Bittorrent Sync as well. This could be accomplished with something like SyncNet: http://jack.minardi.org/software/syncnet-a-decentralized-web-browser/ Or by distributing static web pages via a Bittorrent Sync folder by distributing read-only keys to users of the site. Is anyone interested in working on this with me?
  11. I am working on a project to securely sync several folders to multiple Mac Mini servers as well as my MacBook Air and my desktop machine. The Mac Mini servers will provide backup and versioning of the synced folder data. I trust Bittorrent Sync to keep my data safe during transport. However, I don't trust the colocation personnel who have physical access to my Mac Mini servers. I would like the synced folders to be encrypted on the Mac Mini servers and decrypted only on my MacBook Air and my desktop machine. So I have set up Viivo (viivo.com) to encrypt files in the /Users/username/Viivo folder to the /Users/username/Viivo-Encrypted folder. And I have set up Bittorrent Sync to sync the encrypted /Users/username/Viivo-Encrypted folder. Everything is working perfectly, EXCEPT Bittorrent Sync is creating temporary files with a ".!sync" extension while it is syncing the new/changed file. This causes Viivo to see and decrypt the temporary file and place the decrypted file into the /Users/username/Viivo folder. This leads to a infinite loop of temporary files being added to the /Users/username/Viivo folder with file extensions of ".viivo.!sync", ".viivo.!sync.viivo.!sync", and so on. The solution to this problem would be for Bittorrent Sync to not store temporary files inside the sync folders. Has anyone else worked on adding encryption to files before syncing with Bittorrent Sync?
  12. I am having the same issue on OS X Mavericks with Version 1.2.82 of Bittorrent Sync. I am using Viivo to encrypt the individual files to a folder that Bittorrent Sync is syncing to my other computers. What happens is that Bittorrent Sync creates a temporary file with a .!sync extension to the file name. Viivo then sees that .!sync file and decrypts it back to the unencrypted folder. The end result is that these .!sync files start replicating back and forth between the synced machines. Please implement a change which prevents these .!sync files from messing up the ability of 3rd party software to augment Bittorrent Sync. Thank you!