Hacker News Reader

Comment by dhouston | Hacker News Reader

just so everyone knows, this complaint raises old issues that we addressed in our public blog post a few weeks ago: http://blog.dropbox.com/?p=735

View on HN

Drew,

I use dropbox and I appreciate it, but I find communications from you and Arash to be strangely borderline ... off.

A discussion from three weeks ago is not "an old issue." That these issues made it to the FTC in three weeks is probably a remarkable benchmark.

As Arash did several weeks ago, wrt to the password and key issue, you seem to miss the point and almost intentionally dismiss the issue by detailing it as "old issues."

These issues are anything but old, even in internet time.

I would value Dropbox much more than I do if I found that you and Arash could speak with the integrity I find from so many other entrepreneurs.

The similarity between the messages from Drew, Arash and the spokeswoman Julie Supan mentioned in the article is unfortunate. It makes me wonder if there isn't some memo they're circulating over there, listing all the talking points to hit when talking about this.

Seconded, I dislike the evasiveness I detect and the corporate speak. It ignores the actual problem, which to me opens up even bigger problems when you just stick your head in the sand.

I think the evasiveness is intentional. With 25 million users (http://www.webpronews.com/dropbox-user-base-up-to-25-million...) I think Dropbox likely finds itself friends with govt entities that didn't previously care it existed and would encourage them to keep things the way they are as opposed to going the tarsnap route.

I know this comment could be dismissed as tin-foiley, but spending a week here reading stories on FBI wire taps or bills passing through congress and I don't think this is much of a stretch by any means.

I imagine this is a (necessity?) of modern day, massive-scale online services like this... or at least it becomes one once they hit critical mass.

For example, I would expect Facebook has a back-channel for law enforcement to view profiles unfettered by privacy settings. I'm not saying I have proof they do, but would anyone really be surprised if a service with 700 million users globally was in-bed with security agencies?

I suppose I just expect that now.

You don't have to be tin hat to worry that if "some" Dropbox admins have access to your files, then your files are at risk of being hacked just like what happened with Sony and their PSN. If a company has your stuff, and someone there has the key to your stuff, you'd better be sure it's as important to them as it is to you. Since that is rarely the case, I prefer not to give anyone else the key.

I didn't see this issue addressed in that blog post. It comes down to some very simple questions:

1. Can Dropbox access user files? (already answered, yes)

2. Did you ever claim otherwise?

3. If so, why? And how will you appease any users that were misled? If not, where is the flaw in this complaint and various others?

The kind of vague PR-speak in that blog post will only irritate this crowd and drag the whole thing out. IMHO, the fastest way to make this go away is to take a firm position and state it clearly. And if you don't want to do that then it's probably best to say nothing at all.

People have asked why Dropbox servers need to decrypt user data. The reason is many of the most popular Dropbox features — like accessing your files from the website, creating file previews, and sharing files with other people — would either not be possible or would be much more cumbersome without this capability.

Accessing files from the website and file previews can use a key that I give you when I login. The only one where you need to have a key is if I share the file with someone. Can't you throw up a prompt when I elect to share a file that says, "This file will now be accessible to person XYZ. In order to do this DropBox will re-encrypt with our own private key"?

I suspect a lot of people don't share most/all of their files with anyone. It would be nice to have privacy by default and then opt-out when they decide to share it.

That would prevent de-duplication in the non-shared case, which as I understand it is important to Dropbox for increasing storage efficiency. I suspect that is the primary reason why they don't have an option to "store encryption key locally only" in the client. The excuse that users expect to be able to share and access files on the web can be overcome with a big scary warning indicating that is not possible when using client-side-only encryption keys.

Dropbox advocates TrueCrypt in one breath, but refuses to integrate client-only encryption keys in the client with the next breath. Obviously they know what we all know: TrueCrypt presents a poor UX for non-technical users, and so most people won't use it even if it's recommended. Then DropBox gets to be the hero for advocating TrueCrypt while they get de-dup efficiency because they know few people actually bother using TrueCrypt.

Any transfer of keys to dropbox, even temporally, means your data on dropbox should be considered insecure. You have no way to know what's going on on the dropbox side. The same issue arises for CAs that let customers generate SSL keys within a web interface, to avoid the nuisance of having to generate a key/cert/csr themselves and uploading that. It doesn't matter if the CA promises never to store the private key. It's insecure and it's bad practice.

I would love to keep the keys on my computers if all it meant is I couldn't use the public sharing/web interface features. Using TrueCrypt is a PITA.

Dropbox depends on being able to deduplicate your data.

If they can't decrypt it, they can't deduplicate it.

If they couldn't deduplicate it, the costs would be higher.

Higher costs => higher prices

If a file is encrypted, then that encrypted file can be duplicated. I don't understand your point.

The encryption process doesn't result in one giant blob of data. It results in N blobs, where N is the number of files you store in Dropbox.

EDIT: I misread "deduplicate" as "duplicate". You're correct.

De-duplication requires verifying that two files are identical. If they can verify that two files are identical they either compared them both in unencrypted form or they can compare the two encrypted files. The first method would require them to be able to unencrypt files without prompting all users for their private key to compare the copies.

The second method would require identical files from different users to encrypt to the same form, meaning the encryption is not key dependent and thus can also be decrypted without your key.

There may be some other method I'm missing but I don't see how they could de-duplicate with key-dependent encryption when their users hold their own keys.

de-duplication is the process where if two customers both store the same file, say abbey_road_from_itunes.mp3 the service provider only needs to store one copy of it. They can't do this if they encrypt each copy of that file individually for each customer. This adds up to a lot of space for a service like this, as most of the large files people store aren't their own creations.

Doesn't deduplication make them vulnerable to MAFIAA lawsuits?

It shouldn't - I'm sure they qualify for Safe Harbor as long as they respond reasonably to DMCA notices.

Also, two people can have the same file but only one permission.

An identical file encrypted with key X will be a different blob from one encrypted by key Y. About the best you can do is slice the file into N byte blocks and dedupe on that (this is what some modern filesystems like ZFS do).

I'm actively looking at alternatives. I knew about these issues when they were first revealed a month or so ago, but this just reminds me to actually use something. I'm considering SpiderOak.

I moved to SpiderOak a few weeks ago when this came up first.

Still need a lot of improvement but It's good. Built on different philosophy, so the workflow is slightly different, however in some areas (what to backup, what to sync and how) has more flexibility.

One missing feature is syncing directories with others. Probably the architecture that gives the security makes this a difficult task.

To compensate for that, there's a pretty good feature of web-share. Can share anything you backed up, with a separate password that you can revoke any time.

So in the end: I keep Dropbox but removed most of my files from there, started with SpiderOak, and playing with AeroFS (similar functionality on peer-to-peer architecture).

Reply on news.ycombinator.com