7 ms·

Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the importa

by kijin 13y ago

Seriously? Wuala is a service run by LaCie. LaCie is owned by Seagate, an American corporation. It doesn't matter where the servers are, because all the important decisions will be made in Cupertino, California. http://www.lacie.com/us/company/news/news.htm?id=10722 http://www.lacie.com/us/company/news/news.htm?id=10722 Now, client-side encryption is a much more interesting aspect of their service, but is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices? Ditto for SpiderOak, JungleDisk, and every other backup/sync solution that I've used so far that boasts client-side encryption. And it wasn't due to Dropbox's deduplication, either. Some of them just talked lazily with the server for several minutes before they even started to upload/download any files.

sillysaurus 13y ago
Why not just store a TrueCrypt volume(s) in Dropbox?
- cddotdotslash 13y ago
  Because, as far as I know (I haven't used TrueCrypt too much), it will see the volume as a file and then you'll be syncing a huge, x GB file every time you make the smallest change within it.
  - olov 13y ago
    That's not true. Dropbox uses librsync so small changes of big files yields small diffs, thus TrueCrypt volumes work just fine with Dropbox.
    - missing_cipher 13y ago
      Speaking out of ignorance here: But aren't TrueCrypt volumes completely changed when you add/remove something? I'm thinking similarly to a hash: The slightest modification changes it completely.
      - mkl 13y ago
        That's not how it works - it would be inefficient to the point of uselessness to rewrite the entire file constantly, and my 100GB TrueCrypt volume is fast to save to.
      - throwit1979 13y ago
        If that were the case, then terabyte-scale volumes would be prohibitively useless - and I know plenty of people with media volumes in TC.
      - sigil 13y ago
        But aren't TrueCrypt volumes completely changed when you add/remove something? No, the crypto in TrueCrypt doesn't amplify the number of changed blocks. But it does disperse the changed blocks throughout the encrypted image, and this does result in higher bandwidth used during the sync (at least with DropBox). Here's an analysis I did a few years ago: https://news.ycombinator.com/item?id=2546626 https://news.ycombinator.com/item?id=2546626
- geertj 13y ago
  Storing an EncFS on Dropbox is another alternative, that doesn't depend on Dropbox' ability to recognize small changes in a huge single file.
- adamman 13y ago
  I like Boxcryptor since it encrypts each file individually rather than the whole volume. However, the file names are exposed.
  - mjs7231 13y ago
    encfs. Encrypts each file individually and file name are encrypted.
    - kijin 13y ago
      encfs sometimes generates very long path names, which runs against the 255-char limit that Dropbox imposes if you have any Windows computers linked to your account. Last time I tried it, the filenames were silently corrupted and much data was lost.
- RKearney 13y ago
  This is assuming the Government doesn't force Dropbox to install a keylogger on their client to get users TrueCrypt passphrases and possibly keyfiles.
  - a3_nm 13y ago
    If Dropbox bundled a keylogger with the Dropbox client, I'm pretty sure it would eventually attract some attention...
    - webjprgm 13y ago
      Yeah, 4 years later when a whistle blower said something.
    - pasbesoin 13y ago
      Who's to say they can't be convinced to push a one-off update to your account/machine. Perhaps a transitory one, to help cover their tracks? The underlying problem is that you're trusting closed client software from a third-party. Once that is running on your system, arguably it's game over as far as what Dropbox or its like can and can't do to you. (If you trust them, ok. But when documents state that "they're next", many of us start to wonder. And again, this isn't just access to a server. Through their client software, this is access to your machine, that you've already granted. Admittedly, I'm describing the typical Dropbox user scenario and not where the client is manually applying -- or not -- each update, and somehow supposedly gaining insight into the capabilities of each update/version before doing so. And I'm also ignoring various forms of restricting the access of the Dropbox client, although if they really want you, they and parties using them would have extensive resources to apply to breaking out of such constraints.)
      - mike-cardwell 13y ago
        https://grepular.com/Protecting_Your_GNU_Linux_System_from_Dropbox https://grepular.com/Protecting_Your_GNU_Linux_System_from_D...
        13y ago
- ramayac 13y ago
  That's what I do, I have a small (100 MB) small volume sync in my DB, works like a charm :)
- tripzilch 13y ago
  Because TrueCrypt is not exactly "free and open source" software either. http://en.wikipedia.org/wiki/Truecrypt#Reasonable_paranoia http://en.wikipedia.org/wiki/Truecrypt#Reasonable_paranoia """It is challenging to create binaries from source code that match the official binaries bit-by-bit for purposes of verifying their integrity due to compiler options ... There has been no known comprehensive review of the source code by a qualified cryptographer.[46][44] Thorough security code review and testing is hard, tedious, and painstaking work, and very few people have the skills to do it. There was, however, a functional evaluation of the deniability of hidden volumes in an earlier version of TrueCrypt by Schneier et al. that found security leaks.[47]"""
- tincholio 13y ago
  It'd be better to use EncFS in this case, as it does per-file encryption. With TruCrypt, the whole volume file would need updating once you unmount it, if I understand correctly.
a3_nm 13y ago
> is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices Is this some general FUD about encryption being slow, or an actual measurement? Maybe all client-side encrypted solutions happen to be crappily implemented, but I don't think that client-side encryption would necessarily lead to something noticeably slower.
- kijin 13y ago
  I have absolutely no intention to spread FUD about client-side encryption, and in fact I don't think Dropbox's speed advantage has anything to do with (lack of) encryption. Encryption shouldn't have any noticeable impact on sync speed, since modern CPUs can encrypt a file a hundred times over in the time it takes to upload/download it. I agree with you and suspect that it has more to do with crappy architecture. Anecdote: SpiderOak takes 5 minutes synchronizing metadata with the server if I start it on a laptop that I only use occasionally. That's how long it takes for the client to find out what files I changed in my other machines in the meantime, including all the files that have nothing to do with this particular machine. Nothing gets synched during this time, and the client sometimes consumes a whole CPU core for extended periods. It's very annoying when I just want to see a few files that I know I changed in another machine. I understand that the protocol needs to be different if all the encryption is done by the client, but this is just ridiculous. Wuala is no better in my experience, although YMMV depending on your use case and filesystem structure. (I have over 50GB of data in my SpiderOak account, made up of a quarter million files. At one point I had over 100GB stored in there, and it was a PITA to sync any files at all.) As an interesting comparison, Microsoft SkyDrive performs just as terribly as SpiderOak does when you give it a few hundred folders with ~100K files to sync, despite the fact that it does no client-side encryption. It just sits idle for half an hour or more, scarcely utilizing any network resources. I have no idea what it's doing. Maybe it does sleep(random()); between each upload. In any case, encryption isn't making it slow. It's just bad app design, bad protocol design, and perhaps overloaded servers. Dropbox, on the other hand, immediately begins to upload/download my files, and once it's done scanning any large folders, its speed is only limited by the bandwidth of my Internet connection. When I need to do a presentation, I can just work on the .pptx file in my Dropbox on my desktop PC, take my laptop to the conference room, and expect the .pptx to be there as soon as I wake my laptop. That's the meaning of convenience. By the same metric, none of Dropbox's commercial competitors (perhaps with the exception of Google Drive, which I don't use) are even close to convenient.
jpalomaki 13y ago
BoxCryptor[1] has been my choice. I've been now using it on daily basis together with Dropbox and I'm satisfied. Boxcryptor works on the client side and stores the encrypted files on Dropbox folder as ordinary files. It is also possible to encrypt filenames. Boxcryptor comes from Germany. The only drawback I have encountered is that Dropbox limits the path names to 255 characters. With encrypted file/folder names this can become an issue especially with some Java projects. I think this really gives me the best of both worlds. Security for the files I think need it and the Dropbox infrastructure for syncing files. [1] https://www.boxcryptor.com/ https://www.boxcryptor.com/
- kijin 13y ago
  Yeah, tried that too. Also tried CloudFogger [1], which has a similar feature. When it comes to performance, a layer of encryption on top of Dropbox is much better than any competing solution that has client-side encryption built into it, because you're still using Dropbox's awesome infrastructure and lightening-fast sync protocol. But I ran into the same problem as you did. The 255-char limit sucks, and it's completely unnecessary because even Windows/NTFS allows you to use longer paths (up to 32KB) if you know which APIs to use. I suppose fixing this is not a priority for Dropbox because you normally don't run into it unless you use encryption, and Dropbox has no reason to encourage the use of encryption among their users. [1] http://www.cloudfogger.com/ http://www.cloudfogger.com/
DanWaterworth 13y ago
wuala isn't just doing client-side encryption, it is also doing reed-solomon coding.
mwfunk 13y ago
"...is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices?" I have no idea what the performance difference is (and clearly , neither do you), but the answer to your question is "yes". For some people, at least. It's a must-have feature for some people, not a nice-to-have-as-long-as-it-doesn't-inconvenience-me-too-much feature. Some people have data that they'd like to keep synced across systems that they simply can't keep in unencrypted form on a third-party server, no matter how much trust they have in the company that owns the service. Of course, there are a bunch of different ways to keep your data secure and still have it be available to you on different systems, and non-open-sourced cloud storage with client-side encryption is still an imperfect solution, but it is a solution that is perfectly reasonable for many people.

by kijin 13y ago

sillysaurus 13y ago

Why not just store a TrueCrypt volume(s) in Dropbox?

cddotdotslash 13y ago
Because, as far as I know (I haven't used TrueCrypt too much), it will see the volume as a file and then you'll be syncing a huge, x GB file every time you make the smallest change within it.
- olov 13y ago
  That's not true. Dropbox uses librsync so small changes of big files yields small diffs, thus TrueCrypt volumes work just fine with Dropbox.
  - missing_cipher 13y ago
    Speaking out of ignorance here: But aren't TrueCrypt volumes completely changed when you add/remove something? I'm thinking similarly to a hash: The slightest modification changes it completely.
    - mkl 13y ago
      That's not how it works - it would be inefficient to the point of uselessness to rewrite the entire file constantly, and my 100GB TrueCrypt volume is fast to save to.
    - throwit1979 13y ago
      If that were the case, then terabyte-scale volumes would be prohibitively useless - and I know plenty of people with media volumes in TC.
    - sigil 13y ago
      But aren't TrueCrypt volumes completely changed when you add/remove something? No, the crypto in TrueCrypt doesn't amplify the number of changed blocks. But it does disperse the changed blocks throughout the encrypted image, and this does result in higher bandwidth used during the sync (at least with DropBox). Here's an analysis I did a few years ago: https://news.ycombinator.com/item?id=2546626 https://news.ycombinator.com/item?id=2546626
geertj 13y ago
Storing an EncFS on Dropbox is another alternative, that doesn't depend on Dropbox' ability to recognize small changes in a huge single file.
adamman 13y ago
I like Boxcryptor since it encrypts each file individually rather than the whole volume. However, the file names are exposed.
- mjs7231 13y ago
  encfs. Encrypts each file individually and file name are encrypted.
  - kijin 13y ago
    encfs sometimes generates very long path names, which runs against the 255-char limit that Dropbox imposes if you have any Windows computers linked to your account. Last time I tried it, the filenames were silently corrupted and much data was lost.
RKearney 13y ago
This is assuming the Government doesn't force Dropbox to install a keylogger on their client to get users TrueCrypt passphrases and possibly keyfiles.
- a3_nm 13y ago
  If Dropbox bundled a keylogger with the Dropbox client, I'm pretty sure it would eventually attract some attention...
  - webjprgm 13y ago
    Yeah, 4 years later when a whistle blower said something.
  - pasbesoin 13y ago
    Who's to say they can't be convinced to push a one-off update to your account/machine. Perhaps a transitory one, to help cover their tracks? The underlying problem is that you're trusting closed client software from a third-party. Once that is running on your system, arguably it's game over as far as what Dropbox or its like can and can't do to you. (If you trust them, ok. But when documents state that "they're next", many of us start to wonder. And again, this isn't just access to a server. Through their client software, this is access to your machine, that you've already granted. Admittedly, I'm describing the typical Dropbox user scenario and not where the client is manually applying -- or not -- each update, and somehow supposedly gaining insight into the capabilities of each update/version before doing so. And I'm also ignoring various forms of restricting the access of the Dropbox client, although if they really want you, they and parties using them would have extensive resources to apply to breaking out of such constraints.)
    - mike-cardwell 13y ago
      https://grepular.com/Protecting_Your_GNU_Linux_System_from_Dropbox https://grepular.com/Protecting_Your_GNU_Linux_System_from_D...
      - 13y ago
ramayac 13y ago
That's what I do, I have a small (100 MB) small volume sync in my DB, works like a charm :)
tripzilch 13y ago
Because TrueCrypt is not exactly "free and open source" software either. http://en.wikipedia.org/wiki/Truecrypt#Reasonable_paranoia http://en.wikipedia.org/wiki/Truecrypt#Reasonable_paranoia """It is challenging to create binaries from source code that match the official binaries bit-by-bit for purposes of verifying their integrity due to compiler options ... There has been no known comprehensive review of the source code by a qualified cryptographer.[46][44] Thorough security code review and testing is hard, tedious, and painstaking work, and very few people have the skills to do it. There was, however, a functional evaluation of the deniability of hidden volumes in an earlier version of TrueCrypt by Schneier et al. that found security leaks.[47]"""
tincholio 13y ago
It'd be better to use EncFS in this case, as it does per-file encryption. With TruCrypt, the whole volume file would need updating once you unmount it, if I understand correctly.

a3_nm 13y ago

> is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices Is this some general FUD about encryption being slow, or an actual measurement? Maybe all client-side encrypted solutions happen to be crappily implemented, but I don't think that client-side encryption would necessarily lead to something noticeably slower.

kijin 13y ago
I have absolutely no intention to spread FUD about client-side encryption, and in fact I don't think Dropbox's speed advantage has anything to do with (lack of) encryption. Encryption shouldn't have any noticeable impact on sync speed, since modern CPUs can encrypt a file a hundred times over in the time it takes to upload/download it. I agree with you and suspect that it has more to do with crappy architecture. Anecdote: SpiderOak takes 5 minutes synchronizing metadata with the server if I start it on a laptop that I only use occasionally. That's how long it takes for the client to find out what files I changed in my other machines in the meantime, including all the files that have nothing to do with this particular machine. Nothing gets synched during this time, and the client sometimes consumes a whole CPU core for extended periods. It's very annoying when I just want to see a few files that I know I changed in another machine. I understand that the protocol needs to be different if all the encryption is done by the client, but this is just ridiculous. Wuala is no better in my experience, although YMMV depending on your use case and filesystem structure. (I have over 50GB of data in my SpiderOak account, made up of a quarter million files. At one point I had over 100GB stored in there, and it was a PITA to sync any files at all.) As an interesting comparison, Microsoft SkyDrive performs just as terribly as SpiderOak does when you give it a few hundred folders with ~100K files to sync, despite the fact that it does no client-side encryption. It just sits idle for half an hour or more, scarcely utilizing any network resources. I have no idea what it's doing. Maybe it does sleep(random()); between each upload. In any case, encryption isn't making it slow. It's just bad app design, bad protocol design, and perhaps overloaded servers. Dropbox, on the other hand, immediately begins to upload/download my files, and once it's done scanning any large folders, its speed is only limited by the bandwidth of my Internet connection. When I need to do a presentation, I can just work on the .pptx file in my Dropbox on my desktop PC, take my laptop to the conference room, and expect the .pptx to be there as soon as I wake my laptop. That's the meaning of convenience. By the same metric, none of Dropbox's commercial competitors (perhaps with the exception of Google Drive, which I don't use) are even close to convenient.

jpalomaki 13y ago

BoxCryptor[1] has been my choice. I've been now using it on daily basis together with Dropbox and I'm satisfied. Boxcryptor works on the client side and stores the encrypted files on Dropbox folder as ordinary files. It is also possible to encrypt filenames. Boxcryptor comes from Germany. The only drawback I have encountered is that Dropbox limits the path names to 255 characters. With encrypted file/folder names this can become an issue especially with some Java projects. I think this really gives me the best of both worlds. Security for the files I think need it and the Dropbox infrastructure for syncing files. [1] https://www.boxcryptor.com/ https://www.boxcryptor.com/

kijin 13y ago
Yeah, tried that too. Also tried CloudFogger [1], which has a similar feature. When it comes to performance, a layer of encryption on top of Dropbox is much better than any competing solution that has client-side encryption built into it, because you're still using Dropbox's awesome infrastructure and lightening-fast sync protocol. But I ran into the same problem as you did. The 255-char limit sucks, and it's completely unnecessary because even Windows/NTFS allows you to use longer paths (up to 32KB) if you know which APIs to use. I suppose fixing this is not a priority for Dropbox because you normally don't run into it unless you use encryption, and Dropbox has no reason to encourage the use of encryption among their users. [1] http://www.cloudfogger.com/ http://www.cloudfogger.com/

DanWaterworth 13y ago

wuala isn't just doing client-side encryption, it is also doing reed-solomon coding.

mwfunk 13y ago

"...is it worth the trouble if Wuala's clunky client takes 100 times longer than Dropbox to sync a file between two devices?" I have no idea what the performance difference is (and clearly , neither do you), but the answer to your question is "yes". For some people, at least. It's a must-have feature for some people, not a nice-to-have-as-long-as-it-doesn't-inconvenience-me-too-much feature. Some people have data that they'd like to keep synced across systems that they simply can't keep in unencrypted form on a third-party server, no matter how much trust they have in the company that owns the service. Of course, there are a bunch of different ways to keep your data secure and still have it be available to you on different systems, and non-open-sourced cloud storage with client-side encryption is still an imperfect solution, but it is a solution that is perfectly reasonable for many people.