Hacker News Reader

Comment by grepular | Hacker News Reader

I disagree. All cloud storage providers should have similar policies and should enforce them ruthlessly. Maybe then, people will take client side encryption seriously.

View on HN

I'm sure those who really do wish to store and distribute material that really is illegal or unacceptable will use encrypted file storage.

Once again, it is the open and honest user who is close to an edge case who gets caught up.

I wish all cloud storage providers would prompt an "encrypt with your own key" link before you upload each file, and then do the encryption for you. Of course, then you'll have to trust them with their own encryption method. But if they are using standard encryption methods, that shouldn't be an issue, right?

By "do the encryption for you" do you mean that they should encrypt on what you send them on their side? I'm afraid that gains you nothing. Not only they control encryption method, they also have unencrypted data and your key. Encryption must occur on client side to give you safety, and I would argue against using JavaScript to do it(after all website can be updated without your knowledge, and it is not practical to review site code each time you load it).

In theory, they can do the encryption for you, on the client, and never send themselves the key. However, the effort required to audit a given client and verify that they are in fact doing that, doing it securely, and doing it in a way where they won't later change their minds and grab the key or whatever greatly exceeds the effort of simply handling the encryption yourself.

I understand why people call for this, but it's really a very narrow window of "security concern" where that's a valid feature.

Much better would be an open API, and an open source client, which does the encryption, preferably not even technically affiliated with the cloud provider.

Actually this option exists in practice, not just in theory. See http://www.tarsnap.com/ for details.

The author of that code is the FreeBSD security officer. He is also the author of my favorite comeback ever on Hacker News: http://news.ycombinator.com/item?id=35079

(Or navigate up to http://news.ycombinator.com/item?id=35068 and get some context. cperciva really is impressive.)

Here would be my ideal scenario, but it requires changes at the OS level:

During installation, Dropbox asks the OS for an encrypted read/write view of "/home/user/Dropbox". The OS confirms this with the user. The user sets up the key/password for that encryption. Done.

If Dropbox is compelled in future to try and gain access to the unencrypted view of that same folder, it would have to ask the OS permission, and the OS would ask the user.

Dropbox could also ask for an unencrypted view on the initial installation, but the user should still be allowed to specify that the view it gets is of the encrypted versions of files only. This would be entirely transparent. Dropbox would have no idea if it's getting the full view or the encrypted view.

I disagree. Unless illegal by law, it's your private data. If you share it, it would be something different, but as long as it's private, it's just weird.

Others have them, but as long as you don't use the content PUBLICLY, they don't enforce, which is exactly correct.

Edit: sorry, reread. You are right about the encryption part. I still stand by the rest :)

Thats the thing, for all we know the law states that they have to make an effort to remove child porn, pirated movies, etc.

Well, yes, I see that issue. But also that is not as simple as MS now takes it:

- Childporn; pictures of very young children are stimulating to perverts and while there are definitely very 'wrong' pictures in this category, there are also just pictures you took of your young kids and have in your private folders ; that's not childporn UNLESS a pervert gets his hands on it. Meaning when it is private and yours, it should not be removed. It's memories of your children who naively play in the garden forgetting to put their pants on (I wish I could do that ffs) for instance. In the wrong hands dangerous, private and not shared; perfectly normal.

- Pirated movies; at least here you are allowed to backup movies you own, again if they are private, it cannot be that your account is removed for this; you HAVE the DVDs in your home and you ripped them in case of fire or when the break (and they often do after many years).

Both are crap arguments for removing accounts or even data UNLESS they are made public.

Hence it can be solved very easily ; just scan public dirs.

Does anyone know of any cloud storage with client side encryption that is convenient to use? I'm using Wuala, but would like to hear about alternatives.

SpiderOak (most similar to drive, dropbox), Tarsnap (nix-only, have to compile it yourself), aes.io (browser-based, like box.com)

I mentioned that at Corkboard and mailed the guy about it; http://news.ycombinator.com/item?id=4224524

I've been using JungleDisk for backups. I have it set up to encrypt locally with my key, and the backups are stored in my Amazon S3 account.

Tahoe-LAFS-on-s3 from Least Authority Enterprises https://leastauthority.com

Bonus: one user, 'sickness', showed how to replicate your encrypted data across Dropbox, gdrive, etc. http://www.sickness.it/crazycloudexperiment.txt

HN's own cperciva has created tarsnap.com

He's a crypto expert, so you should check out his service.

Not quite a Dropbox replacement, but Arq for Mac OS X uses S3 for backup, and encrypts your data with a private key that only you know (unless he's surreptitiously sending it to himself).

Reply on news.ycombinator.com