Knox with DropBox?

rogerinlondon

Anyone knows what might happen if you save a Knox vault in DropBox and try to open the file from two machines? Will it get corrupted or will it just not open?

jxpx777

Hi, Roger, and welcome to the forums. Right now there aren't any safeguards in place to prevent the vault being modified concurrently, so it's best to not store your vaults on Dropbox. You can read more [URL="http://help.agile.ws/Knox/sync_vaults.html"]here[/URL] but it's basically the same information. :)

rogerinlondon

Thanks Jamie, I did notice that, but I have also seen a couple of comments about people claiming to have used encrypted disc images for a long time with DropBox without any problems so I was just a bit curious about what risk you could actually run by doing that. What would the problem be?

jxpx777

The main risk is with the vault being open and modified on two computers. I too have stored my Knox vaults on Dropbox without any apparent problems in the past, but I only use one computer and use Knox primarily as a way to back up my files automatically and also to have them available for easy setup if I were to have to use my wife's computer for instance. That being said, I can't make any definitive statements about the integrity of my vaults even though everything I have used appears to be fine. I have since moved all of my vaults to local storage so as to avoid any issues that might be lurking around the corner.

Aaron Gibralter

Does anyone know if concurrent Dropbox access will be addressed in future versions of Knox?

khad

It is an issue with Apple's encrypted disk image technology which Knox makes use of. I do not know of way to mitigate the issue without creating a brand new encrypted image format specifically designed for syncing and concurrent access (read: not a simple task at all). Consider that even a company like Apple has not "cracked this nut." Encryption and synchronization are not normally best of friends, unfortunately.



We never say "never," but it is a feat that I do not think anyone else has ever accomplished.

cmyers

I know, reviving old thread, but this one seemed the most pertinent.



What about using a similar approach as DEVONThink and using a lock file outside of the bundle to control mount access to the bundle? Check for lock before mount. If it exists, warn and provide option to override or cancel the mount. If it doesn't exist, create it and mount the bundle. On unmount, delete the lock.



It doesn't give simultaneous access from multiple machines, but it does provide a safety mechanism for people who cross multiple systems and simply want access to the volume from whichever one they happen to be using at that time.

khad

Thanks for the suggestion, cmyers. I will pass this along to the developers. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

cmyers

You can see the approach I used for doing a lockfile for Things here: http://culturedcode.com/things/wiki/index.php/Sync_via_Dropbox_with_a_lock_file



It will be a little bit different since this would be inside the application rather than on application launch, but it shows the concept and info inside the lock file in case troubleshooting is necessary. It would do the same protection wrap around disk mount rather than on application execution. Lock deletion would need to be a separate step added after the unmount since the original mount won't block lock the application execution does.

maximus

[quote name='Jamie' timestamp='1274975045' post='2613']Right now there aren't any safeguards in place to prevent the vault being modified concurrently, so it's best to not store your vaults on Dropbox[/quote]



Ive read the 'fine print' but the 'risk' remains unclear to me. For me syncing my Knox vault on DropBox is too convenient.



Scenario:

I have a Knox vault stored on DropBox.

It is 'mirrored' via DropBox between 3 computers.

The Knox vault is only ever opened briefly to view a file, or to dump a file into – and only one computer at a time.

The vault is always unmounted after each use and that is when I notice DropBox go into action, presumably writing the changes (or whole vault?)



At what point in this scenario is security at risk?

khad

Thanks for the link, cmyers. I will pass that along as well!



[quote]At what point in this scenario is security at risk?[/quote]

It's not.

Haravikk

Would it be possible for Knox to somehow mark the Vault as in use in such a way that other machines running Knox will know not to edit it? For example, by inserting a hidden file into the mounted image or adding a piece of metadata to the image file itself, with a timestamp telling other copies of Knox not allow changes to be made until the timestamp has expired? This way all an active image needs is for Knox to keep updating the timestamp until you're finished with it, at which point it can be allowed to expire for other machines to have a go.



I suppose really it's more of a thing that DropBox themselves could do with implementing; some method for developers to lock a synchronised file for all other versions of DropBox connected to it, until either the lock expires or is removed.

khad

This is certainly a difficult problem to solve.



As I mentioned in [url="http://forum.agile.ws/index.php?/topic/5047-encryption-and-file-syncing/page__view__findpost__p__28878"]another related thread[/url], "Syncing and encryption are often at odds with each other since the best encryption makes sure that no one has a clue what is inside the file(s) but the best syncing relies on such knowledge to perform delta syncing (syncing only the changes rather than the entire file)."



Something like this would be easier to implement if Dropbox could actually see into the encrypted vault, but I don't think anyone wants that. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



I would be very concerned about a file accidentally being "locked" on all of my machines or the file lock failing. I'm not sure how easy this would be to implement at the file system level either. If Murphy has taught us anything, some application somewhere would be making the "wrong' kind of call and end up corrupting the data anyway.



I'm not saying it is impossible, but I believe it is far from trivial.