Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Privacy, Security and Your Dropbox (dropbox.com)
67 points by AndrewDucker on April 21, 2011 | hide | past | favorite | 55 comments


These are weasel words. Miguel de Icaza's post explains the issue:

> My problem is that for as long as I have tried to figure out, Dropbox made some bold claims about how your files were encrypted and how nobody had access to them, with statements like:…

> - Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)…

> But this announcement that they are able to decrypt the files on behalf of the government contradicts their prior public statements.

Dropbox are avoiding answering this. If they derived the encryption key from your password, as JWZ explained http://www.jwz.org/blog/2011/04/dropbox-doesnt-actually-encr... and as occurred to any halfway decent hacker, they wouldn't need to have the ability for their employees to decrypt your files — an ability which they are still claiming to not have.

And this is just insulting:

> We understand that many of you have been confused by this situation — and some folks even felt like we misled them

The problem isn't that we were confused or what we felt or that we were unintentionally "misled". The problem is that, apparently, you lied to us in order to defraud your customers.


Sorry. I just don't get it. Why are people so surprised by this? I think the people that are shocked are people that just don't bother to think about the devices they use. This is the danger of this whole "ooooh it's magic" shellac marketing craze everyone seems caught up in.

All of this should have been obvious to anyone that bothered to think about what was going on before they stored their precious secrets in Dropbox. Obviously they are holding the encryption keys. Hell, that much was obvious to me when I started using/testing Dropbox just over a year ago and saw my files served over a web page. I can't help but muster a "meh".

The value I saw in their use of encryption is this: when they or amazon or whoever dispose of their drives it will be harder to harvest data off of them. That's all I've come to expect from them and that's all any of their information has ever warranted.

I still derive great value from their service.

Now, I will admit the one that I personally didn't think through back then was the key file thing, but really that's just the same as having an ssh private key. I was aware that it wasn't constantly prompting me for a password so at some level I knew it was going on. Maybe I would prefer some sort of passphrase at login using a keyring for that file. Minor issue.

I do trust them that the run-of-the-mill support personnel are barred from accessing the keystore. Its entirely feasible that there is no mechanism for them to just go browse around your files.

However, it should be blatantly obvious to anyone that understands anything about encryption that someone somewhere at dropbox can access your files. This has always been the case and obvious.

I guess I'm mostly amused by people that are surprised by any of this. The smarter they pretend to think they are, the more amusing they "fell" for something this obvious. It's like the people that fall for mint.com's attempts to obscure the fact that they store your bank account usernames and passwords (oh, sorry, I forgot, they pay a third party to do that for them instead). People just don't think through the mechanisms of their shiny trinkets. You get to just point and laugh.


It is completely reasonable for a layman to believe that his files are protected by a password, and therefore that nobody can access those files without the password. You don't have to be an idiot to have that mental model, especially when Dropbox reinforce it with explicit statements like "Dropbox employees aren't able to access user files".

It's a consumer service, and consumers don't know or care how encryption works. They just need to be told the consequences of whatever technical decisions have been made on their behalf, so it's important for Dropbox to be honest in explaining them.


It's also completely reasonable for laymen to assume that the government can gain access to their Dropbox files. I don't recall Dropbox ever claiming anywhere that they would be technologically incapable of complying with a subpoena.


When they said, "Dropbox employees aren't able to access user files", they were saying they were incapable of complying with a subpoena.


Perhaps. I don't think it's appropriate to edit out the context of that statement. What was actually said was "Dropbox employees aren’t able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)". I don't think that statement as a whole necessarily responds to their capabilities to answer a subpoena. I don't think the lay public would conflate the two contexts.


It's reasonable for a layman to assume that Google can't read his Gmail? That Facebook can't see your private messages? We need to have higher expectations of "laymen."


Why does the degree of surprise matter? That a betrayal is expected does not make it alright.


Agreed. Pausing to think about how it is that you are able to share a file that is stored as encrypted over the web with your friends will provide a clue.

Now, if only there was an cross-platform (mobile + desktop) solution that would allow me to store files I encrypted on Dropbox. That would be pretty killer.


>All of this should have been obvious to anyone that bothered to think about what was going on

This is easy to claim, but we live in a world of tech. You need to step back and get some perspective. We have piles and piles of domain specific knowledge, the layman can barley set up a home router. Dropbox claims to have over 25 million customers. How many of those people do you expect to even have the knowledge to be able to figure this out?

You're putting the burden of realizing dropbox's claims don't hold water on the consumer, who probably doesn't understand a single thing about cryptography. Even if every one could figure it out, they still shouldn't have to.

>I guess I'm mostly amused by people that are surprised by any of this.

I wasn't surprised by any of this, what I am surprised by is people who see others trying to raise consumer awareness and are so quick to dismiss them just because they happen to be among the few who actually do understand the technical limitations of the cryptography implementation used.


I think it's more a question of poor wording than a deliberate attempt to mislead.

No-one with any technical expertise would think that Dropbox was incapable of reading stored files. They'd have to know the encryption key in order to provide their web interface.

So as a technically proficient user, my interpretation of their statement is that they don't give normal employees access to their production encryption keys. However, if the government asks, then presumably they have a legal responsibility to comply.

My guess is that the Dropbox employees who made those statements were also technically proficient, and made the same assumptions I did.


> No-one with any technical expertise would think that Dropbox was incapable of reading stored files.

I did. That is exactly what they made me think.


Really? Maybe I'm just unusually cynical, or I guess maybe I knew about the web interface and you didn't?


I don't think they've lied, I've always known about the fact that they manage the encryption keys, it was one of the first things I looked for when the service was launched.


You still haven't explained what it is you expect them to do.

In reality.

Knowing that they have millions of customers, and that they have invested years of work into their current infrastructure.

So, playing devil's advocate for the moment --- and taking the above facts into account --- what, precisely, would you do in their position?


JungleDisk uses an encryption key protected by an additional password. To access your files online you have to provide this additional password which is used to decrypt the encryption key for the actual data.

Granted, they can still steal your password...


Let me be more clear.

You are now Drew. You start this morning by visiting Hacker News. "Dear god," you exclaim, "I've been such a fool! We've been Doing It Rong all these years!"

Inspired by this new revelation, you spring out of your chair and out the door. You stride into "The Programmer Pit" and over to the new hire, backhanding him across the face. "Get the hell off of Portal 2! We have work to do! Jessica, go pick up four cases of Red Bull --- It worked at MIT, it'll work here."

Now that you have Acquired Their Attention, you say, "Okay, here's-a what we gonna do. Step 1: Jimmy, I want you to ..."

... Now. What, exactly, fellow HNers, is Step 1? Fill in the blank.

What, step-by-step, do you want Dropbox to do?


Can't we all agree, at least, that step one should be to clearly admit that they lied?

Maybe they don't need to do anything else. Dropbox is a fine service as it stands; security must be traded off against convenience, and the trade-off that Dropbox makes is acceptable to lots of people. They do have a responsibility to make sure that those people understand the trade-off, though, as well as a responsibility to admit that they've swept important details under the carpet in the past.


1. Say "we take reasonable precautions to protect your files, but we are capable of accessing their content at any time."


I suspect the truth is closer to:

"Our goal is for no single employee acting alone is able to access your files. However, there is a procedure where multiple people working in concert can recover your files and provide them to law enforcement. Unfortunately, it is possible for a hacker / programmer to create a backdoor and there is nothing we can do about this."


Add an option to create secure folders which are encrypted client side, using a key which is only available client side. these folders wouldn't be usable with things like the web interface because there is no server side capability to decrypt their contents.


"But Drew!" Jimmy exclaims, "What if someone uses Dropbox at work and at home? Are these special folders going to be synced across computers? If so, how will the key be easily transferred (email, USB stick)? What happens when the user's hard drive crashes and his key file is lost permanently? Otherwise, if these special folders won't be synced, then what is the point of the folders being in Dropbox at all?"


Those are just minor implementation details. Off the top of my head, the key can be stored as a password protected file inside the Dropbox account its self, synced like any normal file, but perhaps hidden from the end user. The encrypted folders contents are synced like any others. On any client where you want to access the decrypted folder contents, you'd just enter the password to decrypt the password protected key and the folder contents would become available. If you forget the password then you're screwed.

The only way Dropbox could access those files then would be to backdoor the Dropbox client. But if they were going to do that, it wouldn't even be safe to use TrueCrypt or GnuPG either.


Why wait? Do that today: use ecryptfs.


Will that work with the Dropbox clients on my Android phone, my Android tablet, my Windows desktop, my OSX laptop and my Linux server? If not, then it's no use to me.


It works well for me (primarily linux, also Windows in a linux-hosted VM with dropbox served locally via samba). ecryptfs is standard on Debian and Ubuntu (very likely Redhat as they develop it). I have noticed some efforts to get ecryptfs running on the sdcard/data partitions in Android, but I haven't tried them yet. I haven't used Dropbox on Android since I learned their mobile client doesn't use https. As far as OSX goes, I don't know and I'm unlikely to care.


The Android and iOS mobile clients don't currently use HTTPS for transferring meta-data, but do for file contents.

ecryptfs isn't a suitable alternative to my suggested solution which would involve all Dropbox clients having the capability built in. Of course, people who are really paranoid can use their own layer of encryption on top as well/instead.


Paranoid, functional, existing, and "unsuitable" trumps vaporware. :)


Fair enough, but having something built in to Dropbox for people who value convenience wouldn't prevent anyone from using solutions like ecryptfs as well.


I resent that you sent the female to fetch drinks. Mix it up once in a while and send the queer.


In the beginning, JungleDisk allowed users to manage their own keys from the client-side without ever sharing the key with JungleDisk. I think they dropped this feature subsequently, and there must have been a reason... too many problems with users losing their keys?

Encryption is always a trade-off, since it introduces the possibility of total data loss if the key is mismanaged.


What do I expect them to do? In reality? I expect them to continue to lie, defraud their customers, and attack the credibility of anyone who criticizes them, treating this as a public relations issue instead of an issue of personal integrity.


> So, playing devil's advocate for the moment --- and taking the above facts into account --- what, precisely, would you do in their position?

That depends on the law. Is it legal in the US to store someone else's strongly encrypted data on one's server? Assuming it is, then they should encrypt by default and then if law enforcement forces them to give up data, give what they have.


Why should any critic have to explain what they should do? Perhaps they can do nothing. This doesn't absolve them of guilt.

Personally, I'd let them off the hook if they admitted their previous deception and explained the limitations of their security model in terms that any user can understand.


Personally, I can't see that they can do much more than this. If they're going to supply access via the website, or allow you to share with others then they need to be able to decrypt the file.

I never assumed that it was impossible for them to get access to my files. I just assumed that only certain people had access to the keys, and they only gave them out to third parties when forced to by law.


I think that part of what's going on is that savvy users have become wary of trusting companies to securely manage their data. I first started reading Slashdot shortly after they launched; that was almost 15 years ago. It wasn't long after their launch that they started running articles on technology companies doing bad or stupid things with users' data, and there have been so many examples on so many forums in the intervening years that, to be honest, I'm literally disgusted every time another one comes around.

Trusting companies to, for example, only give access to our data when forced to by law just doesn't cut it anymore, for a lot of people. Not when companies collectively have a very poor track record in this regard, and not when the law continues to be murky and dynamic (and abused).

It's the abused dog effect: even if you, personally, treat a previously abused dog really well and swear up and down that you will never hurt it, if you raise your hand around it, it'll cower.

Since technical solutions exist for this problem, Dropbox's reasoning gets a bit thinner.

> If they're going to supply access via the website, or allow you to share with others then they need to be able to decrypt the file.

Not necessarily. For example, a key derivation function could be used to transform a password into a key, and that password could be required for users that want that kind of thing. As far as website access goes, I'm about to commit a terrible security crime here and suggest that the key derivation function could also be run in the browser. This would prevent direct access to your data by anybody at Dropbox, at least until the next time you log in, at which point they could serve up some malicious code that would record your password and ship it off to them. There are workarounds for that, too, though.


> If they're going to supply access via the website, or allow you to share with others then they need to be able to decrypt the file.

They need to be able to decrypt the file right then to give you access via the website. They don't need to be able to decrypt the file the rest of the time. If the encryption key depends on your password, this is easy to implement. In modern browsers, this could actually be done in the browser, so that the keys for decrypting the file never reach their servers.

To allow you to share individual files with others, they could encrypt each file with a randomly-generated session key, which is encrypted with your user key. When you give access to the file to a recipient, you would be encrypting a copy of that session key with the recipient's public key.

In actual fact, it appears that anyone who knows the secure hash of the file's content is able to discover that Dropbox is storing it: http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u... — and there's at least well-founded speculation, if not proof, that this means that knowing the secure hash is sufficient to read the file: http://news.ycombinator.com/item?id=2440074

For their previous statements to be true — that their employees have no access to your files — they would have to be doing something like this.


Making it password dependent means that they have to decrypt/encrypt when you change password.

And also that you losing your password is apocalyptically bad.


There are some ways around that, but basically you're correct. (For example, you could store the user key, or an additional randomly-generated password, persistently on client machines, so that you can usually recover from password loss; and you could use a tree of session keys to minimize the amount you have to re-encrypt. But basically you're right.)

It's understandable that they chose a less-secure system design. It's not understandable that they chose to lie to their customers about it.


Oh, I totally agree. Honesty up-front would have been a much, much better policy.


I love that they openly in this post discuss that the end-user can use TrueCrypt if they desire:

"For users who feel more comfortable managing their own encryption keys, we recommend using products like TrueCrypt to store encrypted volumes within their Dropboxes. Those users will unfortunately lose access to some functionality, but we leave this decision to the user."

It's the sign of a good company in my opinion that they don't treat their users as unable to understand such things.


Except that when you use TrueCrypt most of the functionality of DropBox stops working; you can't access your files through the web interface anymore (duh), but most importantly, you can't use the volume on two machines at the same time.


I've used TrueCrypt volumes with Dropbox before, and when I encountered a situation where I wanted to access the volume from two places, I took the sensitive data from Dropbox and just exposed it on my private network where I have more control over access. As far as I can tell, there isn't a great way to keep high security and flexibility when using sensitive data with Dropbox, but keeping sensitive data on the cloud is always a risky affair anyway.


This isn't legal advice, but this seems to meet the same legal requirements that big companies must adhere to when using outsourcing providers that will have access to sensitive client data.

The magic words: "Like most major online services, we have a small number of employees who must be able to access user data when legally required to do so. But that’s the exception, not the rule. We have strict policy and technical access controls that prohibit employee access except in these rare circumstances. In addition, we employ a number of physical and electronic security measures to protect user information from unauthorized access."


Its not about the fact that they comply with court orders, of course they're going to, it is in their ability to give the courts unencrypted data that they shed light on the real issue to do something they said was impossible.

If it were impossible for them to get at the unencrypted data, the encrypted data would be all that that had to had over.


If anyone wants to vote for a feature of client side encryption there is a votebox here: https://www.dropbox.com/votebox/21/client-side-encryption


This sounds as if they are doing users a favor:

We manage the encryption keys on our users’ behalf.

To be completely clear to users, they should instead write:

We hold the decryption keys and can decrypt your data if compelled to do so. If you don't want us to be able to decrypt your data, encrypt it yourself with GPG or OpenSSL before sending your data to our site.

Edit: Spelling & clarity.


No, they shouldn't write that.

Dropbox is a consumer file storage company. Statements like that will confuse the majority of their target market and stall adoption of the service.

What Dropbox is doing in relation to security/encryption is about the best possible solution that balances features and function with data protection for files that might be leaked or stolen.

If you have suggestions for Dropbox, lay out concise technical suggestions. Writing new legalese for them is not solving any of the problems that people are getting so worked up about.


Either way, those users will not understand the security of the service they are using. At least with the long version, they'll be aware of their lack of understaning.


They said almost exactly that. "If you want to be completely secure, use a program such as TrueCrypt to create an encrypted drive within your Dropbox."


I actually really like that they did a point by point response to their critics. To me this is an important step for today's companies. The internet gives a voice to customers to raise concerns, companies are able to see these concerns immediately, and companies have a great way to respond quickly. I feel like it this type of dialog creates a win-win situation for everybody involved.


I think it's impossible to have deduplication (a system to prevent duplication) in encrypted data with different key for each user (the same file from different user will be encrypted differently) without dropbox storing the key (to decrypt back). Which means they have access to the files. We should know this from the very beginning. If it wasn't, how to check the files for deduplication? Enlighten me please.


If Dropbox has one key per user, then how do they do deduplication? We know they do deduplication (http://tinyurl.com/4276pxu) so this suggests a very small number of keys.


Storing unencrypted file hashes is the easiest way I can see to do it; then, for deduplication, the file is decrypted using one user's key, and a copy is made and encrypted under the second user's key.


Holy cow, one request per month is low? I know that's less than one account in a million, but that's still way higher than I expected.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: