I'm surprised Jon Callas hadn't realized Dropbox is able to decrypt your files. It always seemed obvious to me given several of Dropbox's advertised features necessitate it (in particular accessing your files over the web interface, and probably their sharing features). Most users wouldn't understand this, but the founder and CTO of PGP Corp should.
That said, this article is incorrect on at least one point: de-duplication does not require Dropbox be able to decrypt your files. tzs came up with this clever scheme in a previous comment: http://news.ycombinator.com/item?id=2461713
Of course even if Dropbox didn't have the keys to decrypt your files you're still trusting them (or SpiderOak or Wuala or most of Dropbox's competitors) by running their proprietary software. But I suppose people are more concerned about subpoenas and compromised servers than malicious actions by Dropbox themselves.
> Of course even if Dropbox didn't have the keys to decrypt your files you're still trusting them (or SpiderOak or Wuala or most of Dropbox's competitors) by running their proprietary software.
You don't have to trust tarsnap. Block encryption happens client side using open source software.
I wish tarsnap was in the same game as Dropbox, I'd pay for it. But as it stands Dropbox is an extremely convenient, general-purpose "network folder". And tarsnap is a backup-tool for unix admins.
I guess this wasn't meant as a feature comparison between both tools but as proof that it is possible to create fully transparent tools for sharing encrypted data across the internet.
I'm not sure why this gets brought up with Dropbox.
Of course it's possible to provide a service which only receives and stores encrypted data. At that point Dropbox would cease to exist. Half the posts about dropbox are lauding it for doing one simple thing well. Your Dropbox/ folder is shared with no fuss.
The other half of posts about dropbox are ribbing on it for not being secure enough.
Here's a clue: If I had to carry an private key with me to decrypt data stored in dropbox i might as well just carry the data.
The scheme tzs came up with provides questionable security, which was also pointed out by other commenters. It offers no protection against hiding the fact that you are in posession of a known file.
For instance, say you are a whistleblower and you have a stash of documents nobody should know you have. Your opponent, having a copy of those documents, can produce an identical encrypted file. What's more, Dropbox obviously already has a mechanism to look up digests so checking wheter the document is stored with Dropbox or not is probably a matter of milliseconds.
Also, as someone pointed out, deriving the key from the cleartext is probably a very Bad Idea.
The only workable approach I can think of is to encrypt and decrypt data on the client. Any scenario where encryption takes place on the server is suspect.
My personal workaround for this is to use Dropbox to store encrypted filesystem images that I can mount on my machine. This severely limits the usefulness and performance of the service, but has turned out to work reasonably well.
Precisely this. Encfs is particularly good for this if you're on a unix-y environment. Otherwise, TrueCrypt might fit the bill (though concurrent access from several machines can be an issue)
True, but I don't think that's a concern for most people.
What are the practical implications? The only one I can think of is if someone were trying to prove in court that you had a particular file.
A related question I've been wondering about is whether a hash or key+ciphertext are considered proof of possession of the original file. In theory an infinite number of files have the same hash, and the ciphertext could have been produced using a different key (or it could just be random data). In practice it's extremely unlikely (for sufficiently secure hash and encryption functions). What are the laws'/courts' views on cryptography?
Doesn't the theory of infinite collisions existing, require that you are nit restricting the file size? The combination of "the hashes match" and the file sizes are roughly the same would seem to go beyond a reasonable doubt.
Not really. Let's use for example a 256 bit hash and a 1KB file. That means you have about 2 ^ (1024 * 8 - 256) collisions that are the exact right size. Close enough to infinite for any file that's at least a hundred bytes. The more pressing concern is how hard it is to fake a particular hash.
>True, but I don't think that's a concern for most people.
But that is the kind of thinking that lead to the whole issue with Dropbox in the first place. Its deceptively "secure" to any user who can't analyze the implementation implications themselves.
Well, yes, that's the point of the deduplication. If you already have the same exact file, in its entirety, you can check if it's in the system or not.
Regarding tzs's system - it fails in two particular aspects: Web-based upload of files and adding a new hash/key to the database encrypted with your password.
Well, fails in that the current operation of Dropbox was a clue that they were not employing anything like tzs's system.
Web-based upload would have required three time/CPU intensive steps: Hashing the contents of the file to create the related encryption key, encrypting the file with said key, then re-hashing the file to get the new "fingerprint" of the encrypted version.
The reason this would all be required is that Dropbox is not only worried about deduplication for storage - they're worried about it for bandwidth saving. When you upload a file to Dropbox that they've "seen", they give you instant upload credit for it and skip the entire process (which users enjoy for the speed and they enjoy for the pocketbook in bandwidth savings).
With an appropriate hash and a block ciper choice, yes, they could do this without creating a client-side duplicate/encrypted file. They could do it as they go (hash the entire file, start encrypting it into a short buffer, then start hashing the buffer) - but if they're not storing a duplicate/encrypted copy locally, they're going to have to re-encrypt it as they go (again) during the upload phase.
So that's: One hash for the key, one encrypt + rehash for the fingerprint, then one more re-encrypt for the upload.
... and then you would run into the other problem I mentioned - where you also have to download the remote database, decrypt it locally, add your new entry to it, then re-upload the encrypted version. All from the web client.
Considering how quickly the upload starts - it's pretty obvious they're doing nothing even remotely like this.
(I understand that we know for a fact Dropbox has access to the files on their servers - I just wanted to expand on the proof that, based on how they were operating, that they couldn't possibly not have access. But then, I've been saying this all along.)
I feel like I should point out that this article isn't about the FTC doing something, but about a private individual filing a complaint with the FTC, which anyone can do.
I like Ryan Singel. He was the first reporter to write about YC. So I can't really begrudge him the pageviews he knew he'd get from HN over this. But 'taint really news.
But I'll disagree about the news value. The complaint's allegations about what Dropbox promised, versus how the architecture actually works, are pretty strong.
Soghoian knows his tech and he knows the FTC (he used to work for them). I like Dropbox. I use Dropbox. But the blog post Dropbox keeps pointing to doesn't explain the discrepancy between what users were told about security/privacy and how the service works in practice (centralized encryption keys).
I agree with Ryan -- this is exactly the kind of news I want to see on HN. For that matter, many other HN readers may also be interested in knowing the potential costs of making apparently-exaggerated security claims in today's environment.
Can anyone explain to me how the article or even title of the article would make someone think the FTC was doing something and then require such a statement from pg?
It is referenced in both as a complaint and is news for wired readers, not necessarily here (though the FTC complaint being filed here is new).
That was my fault. I originally wrote the hed as "FTC Complaint: Dropbox Lied to Users about Data Security", which I thought would get around people reading just the "Dropbox Lied To Users" part. PG changed it to the hed from the article, I suppose to make sure nobody thought the complaint originated from the FTC.
The FTC regulatory model depends on market participants to tip them off when companies are breaking consumer law, so this could be the first step in an eventual action against DropBox.
Callas tweeted on April 19: “I deleted my Dropbox account. It turns out that they lied and don’t actually encrypt your files and will hand them over to anyone who asks.”
That's actually a lie too. Dropbox does encrypt your files, it's just that, naturally, they hold the key. If I ask Dropbox for another users files, guess what? They don't hand them over.
If your info is really that sensitive then for heavens sake don't outsource encryption and key management to a third party you have no supervision over. Encrypt your super sensitive files with Truecrypt and then share/sync them with Dropbox.
Dropbox does encrypt your files, it's just that, naturally, they hold the key.
Even if dropbox's claim was technically correct, it was absolutely misleading. When you say "this data is encrypted" people assume that you mean "... in a way which adds security"; if the same people who have access to the encrypted data also have access to the decryption keys, you might as well be using ROT-13.
If I ask Dropbox for another users files, guess what? They don't hand them over.
Modulo the recently-fixed vulnerability which allowed you to download data if you knew some hashes, that is.
I wouldn't call it a vulnerability. The only way it could be abused would be tricking someone with the file into calculating very specific hashes and giving them to you.
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?
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.
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.
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).
"President Obama Personally Executed Bin Laden, HN Comment to CIA Alleges."
Seriously, who cares where the "complaint" was sent? Either it's a valid argument or it's not. Where it was sent should have no bearing.
The argument that Dropbox did this to save money is transparently bogus too. That's in there to make it seem like the FTC has grounds for getting involved.
Dropbox clearly chose to store keys themselves so they could offer core features like web/pubic sharing.
This is key. Dropbox needs to work as a backup solution, not just as a file sharing convenience solution, because that's how users will actually use it. This potential conversation doesn't sound good:
Grandma: My computer crashed, I got a new one, but I've forgotten my dropbox password.
Dropbox: Okay, can you go get the printout when you registered saying "print this out and never lose it"?
Grandma: I didn't print that out / I lost it / the house burned down.
Dropbox: Sorry, then you're screwed because we designed our service to be usable only by those who have a deep understanding of computer security.
You're putting your files online, and there's a Web interface to access them, and you expect them to be absolutely secure - really? Encrypt them with something really solid and don't put them online, if that's your concern.
You upload your files to the cloud, and then you complain when the company hands them over to the FBI - really? Bury the files in concrete at midnight, and kill all witnesses, if that's your concern.
The guy who is agitating the whole thing - I'm changing my mind about him. He did a good job with the whole Facebook / Google debacle, but now he's coming off as an attention seeker / karma whore.
A lot of this does not make sense to me. Dropbox allows you to view your files via a web browser interface. Obviously that means they can access the unencrypted files. Perhaps people would prefer not to have the web access features.
But even then, if Dropbox never stored the decryption keys on their servers anywhere, and the decryption key was stored only on a client PC, and I lost my computer, I would not be able to access the backed-up data from Dropbox on a new computer. That would kind of defeat the purpose of Dropbox for me. As many others have pointed out (including Lifehacker) you can always use Truecrypt to put some stuff in your Dropbox that no one but you can decrypt.
As far as the "feds" getting my data, if they are after me, they can get a search warrant from a judge and come into my house and confiscate all of my computers, which would allow them to access any data on my harddrives not encrypted with Truecrypt...
It is always easier to destroy than create. Soghoian is into notoriety. He could have gone to them and said "hey, I think you can fix this by doing X, Y, and Z". If ignored, ok, then go public.
He slags off PR guys, but his goal is PR for himself.
I think this is different from the usual situation where somebody finds a vulnerability and goes to the vendor to see if they'll patch it instead of immediately going public. He found that they were apparently deliberately misleading consumers about how they were handling their data, in a way that easily may have lead to users trusting them with data that they might not have if they'd been upfront about their key management. I think an FTC complaint is entirely justified.
You're definitely correct about him being a PR seeker. I'm not too familiar with this fellow, so if he is slagging off PR people it would certainly be hypocritical, but so what? I think this guy is providing a valuable service by exposing misconduct by tech companies.
Well, "misconduct" and "deliberately misleading" are pretty strong charges for a technical matter. There's always a tradeoff between security and convenience. Soghoian's framing of the issue is completely sensationalistic, befitting of MSNBC or Fox News.
I mean, reporting it to the FTC? The same FTC which fined Rock Star over the Hot Coffee mod? Which went after Viacom for Janet Jackson's wardrobe malfunction?
Unfortunately, government officials are not philosopher kings capable of making fine discernments among encryption protocols.
Gah. I just told our corporate counsel that it was ok to use Dropbox because everything was secured "even the app" and all the files were encrypted on Dropbox's site.
It's all relative. The problem was somewhat (unintentionally?) misleading marketing and disclosure, not their actual architecture, at least for most uses of dropbox.
Dropbox seems to have decent transport security, which is more than 99% of apps. Keeping files in dropbox might also keep unencrypted and out of date copies from persisting on local drives, random USB thumb drives, borrowed computers, computers at the print shop, etc.
Yes, someone who compromises dropbox, or a rogue high-level dropbox employee, or a law enforcement officer with a warrant, could get access to your files on disk at dropbox. Dropbox is probably not the weak link, though.
For a normal user (individual or corporate), trusting dropbox is not any worse than trusting gmail or anyone else who has your data and has market, legal, and other reasons to keep it safe for you. I've met with a bunch of top-tier attorneys in the past couple weeks, and none of them want to mess with PGP; they trust that if gmail or an outsourced exchange provider were snooping on their messages, there would be legal recourse; sure, it's an issue if there's no way to prove it, but generally they are pretty trusting of major service providers.
I personally don't use dropbox for anything except "public" files, because I try to constrain long-term storage of my data to my own infrastructure, or something encrypted end to end and fully under my control. However, dropbox is probably a cut above the effective level of security most organizations or individuals have in practice.
I'd sure prefer if dropbox did client-side encryption and never had access to the keys, but then you'd also need to trust that the dropbox binary doesn't secretly send your password to Russia, and that no future version of the dropbox binary that you use has the send-to-Russia feature added. And, you'd need to trust that none of the devices from which you access dropbox has been keyloggered, trojaned, etc.
Of course, dropbox seems pretty robust in terms of availability; I just lost an SSD which didn't have timely backups of certain files, something which is going to ruin my weekend and which would have been avoided had I been less paranoid and used dropbox more.
(and, I'm working on solving the issues with trusting remote services, actually...)
| For a normal user (individual or corporate), trusting dropbox is not any worse than trusting gmail or anyone else who has your data and has market, legal, and other reasons to keep it safe for you.
Except Google doesn't (afaik) lie about their ability to en/decrypt or view your personal data.
Yeah, both points are true. At least it looks like they are fixing the mobile app ssl thing.
I think lying is a bit excessive as a description; they were misleading, hopefully unintentionally, on something where full and clear disclosure would have been a better standard. It isn't like Crypto AG or other famous vendor vs. users situations, though. Ascribing malice to them seems inappropriate.
> Encrypt with Truecrypt, share with Dropbox. Problem solved.
Not so fast. How big is the binary diff when you change a file within a Truecrypt volume? Ie, how much Dropbox bandwidth will you be using, even with a small change?
I performed the following experiment. Start with a 250M Truecrypt volume. Mount it. Create a 1M file from /dev/random. Unmount the volume.
Now, look at what blocks in the Truecrypt volume file have changed. Dropbox uses a 4M blocksize [1].
Conclusion: in this case, Dropbox will transfer 32M (8x the normal 4M) because I added a 1M file to my Truecrypt volume. Note: I haven't tried adding bigger files, but suspect the number of blocks changed will go up linearly but steeply with the size of the added file.
It's not actually that surprising that TrueCrypt mixes file changes throughout the volume file.
Why bring this all up? Because something that does client side block encryption (tarsnap is an example) would only transfer the affected block. 4M, if that's the block size.
And you don't have to trust the cloud storage provider at all.
EDIT: My pipelines were wrong on the first go, suggesting a much larger number of differing blocks. Sorry about that.
Except then you can't use those files on mobile devices or from the web UI, both of which are useful (my primary interest in dropbox, and the one thing I can't trivially accomplish on my own, is the iOS device support. The alternative is just to use Apple's iDisk, which has exactly the same risks as Dropbox, minus the cross-platform capabilities.)
I'm not sure if it's helpful to you, but I use Keypass & Dropbox to sync some encrypted data to my Android phone. It's limited but useful for storing sensitive text. There is an iPhone app: http://ikeepass.de/
I use 1password and wifi syncing. I asked them to add WebDAV support to store the bundle, which is how omnifocus does this, which is probably the most cloudiness I will accept for my password file.
...charges that Dropbox “has and continues to make deceptive statements to consumers regarding the extent to which it protects and encrypts therir data,” which amounts to a deceptive trade practice that can be investigated by the FTC.
What really worries me about de-duping is what if it fucks up your files. What if one file just happens to have the same hash as another completely different file uploaded by a different person? Then all of a sudden, this really important contract that you think you have stored online and in the dropbox folders of your four different computers gets automatically deleted and replaced with a completely different file everywhere. And if you have set up automatic backups like a good boy, it may even be automatically replaced in all your backups before you figure out the problem.
I know you will say that the hashes are long enough so this should not happen until dropbox has trillions of files, etc. But those calculations are all based on assumption of random data in the files. We all know that various computer files may have structured and patterned data. It is possible for the data in certain types of files to be structured in such a way as to produce a much narrower range of possible hashes than generally assumed.
And with 25 million users and hundreds of millions of files, God knows what may happen.
As long as they're using a reasonable hash, that probably won't be much of a concern any time soon. To give some context, a 256 bit key space is about enough to uniquely identify every atom in the known universe.
That is an impressive fact, but not really relevant IMO. There are many more possible files than particles in the universe. A hash does not uniquely identify a file from all other possible files. This follows from the definition of a hash function.
It's not going to happen unless an attack is discovered on the hash algorithm, and even they they'll need to know the hash of your file. And it's still not going to replace the version you have on your computer; only fresh downloads from dropbox will be wrong.
More likely, and worrying, is that it could happen by accident.
Hashing is not the same as compression - we should all know that by now. Pigeonhole principle and all that.
In a 256 bit hash, there are 2^256 possible hash values.
There are far more than 2^256 possible values that can be hashed. Therefore, hash collisions are inevitable.
There is no way to take a hash and expand it back to a unique original value, or it would be a compression algorithm, not a hash.
I don't buy that argument. We have about 2^70 bytes in the entire world. To collide accidentally you're going to need to approach 2^128 items in dropbox. That's not 'inevitable'.
Also, keep in mind anything that could conceivably be called a "file" is fundamentally an arrangement of atoms in a measurable state which can be resolved into an ordered sequence bits. Whether that's a capacitor holding or not holding a charge, of a bit of spinning iron oxide with a measurable magnetic orientation - any actual "bit" is made up of many atoms, and any ordered collection of bits requires many more atoms to hold them in their ordered arrangement (and many more atoms to provide the capability of reading this bits).
A terabyte is 2^40 or ~10^12 bits. A hard drive weighs, what, a few hundred grams? Guessing an average molecular weight of ~50, that represents something like 10^24 atoms - suggesting a "bit density" of around 10^12 atoms are required to store each bit.
Even if you turned every single atom in the universe into hard drives to store your files, and stored every possible arrangement of bits you had space for in all that storage, your chances of a 256 bit hash collision is still way smaller than your chance of winning the lottery.
Big numbers are often confusing. 2^256 is a very bit number. Although abstract mathematics makes if easy to say "yeah, but 2^512 is bigger", it's only bigger in an abstract sense, and not useable in any arguement along the lines of "well, if I had 2^512 physical objects"...
The probability of a hash collision between n files if there are N possible hashes, assuming that each hash is equally likely, is roughly 1-e^(-n^2/(2N))[1]. Let's suppose that there are roughly a trillion, that is, 2^20, files; this is way more than the actual number of files, by the way. And let's suppose that we have a 256-bit hash such that every 256-bit string is equally likely(a reasonable assumption as long as the hash hasn't been defeated)--the number of possible hashes is 2^256. So the chance of a collision is roughly 1-e^(-2^80/(2^257)); since the number inside the exponential is so small, we can approximate it as 2^-177, or less than 10^-53. That number is so small that it's more likely your office will get hit by multiple independent meteors.
Again all of this assumes unifrom distribution. The files used in dropbox are not guaranteed to be random or uniformly distributed. As I already said in my initial comment, various different files types have internal structures which may (again if you are unlucky) result in multiple different files of those types tending to have similar hashes.
One of the goals of a good hash is a uniform distribution. The source files don't have to be random at all. I wouldn't put any money on the odds of by accident hitting a systematic flaw that security researchers haven't yet found in analyzing the hash.
That said, I think it will be possible to deliberately create a collision in SHA256 at some point in the future.
I've never been a Dropbox user, and this sort of behavior doesn't surprise me. It puzzles me why folks are prepared to spend substantial amounts of money renting tiny amounts of insecure web storage when they could spend a modest amount on a plug computer and have a large amount of fairly secure storage, and without the indefinite rental fees.
A year ago, I purchased a Seagate Dockstar (plug computer) and did just what you are saying.
That Dockstar currently turns on and blinks amber. Seagate tells me it is dead.
That and the puny bandwidth of my cable connection and the costs of backing up my diskdrives, leads to a desire to outsource that pain.
So whether it is Dropbox, Google, Wuala, or many other solutions, I would like to find reasonably secure cloud storage, and I would be willing to pay for that (and I do.)
Puny bandwidth is going to be a problem whether the server is your own or exists at some unspecified location in the cloud.
Cloud storage isn't necessarily bad, but it's expensive considering the cost of storage these days and it might be a good idea to encrypt anything that you don't want to become public information before uploading it onto a cloud server.
There is also the sense I have though, that what I am paying for is also:
a) their raid on my files
b) their electrons
c) their sysops and their training and certification and their corporate deals with seagate, and netapp, and cisco, ...
As I said, my dockstar died, I will replace it with a USB hub, but, it is a bit of a pain when what I would prefer to be doing is anything more interesting, fun, or profitable.
Regarding puny bandwidth, I am not sure I understand your point. I get about 12M down and about 600K up, and my understanding is that is fairly typical for a home cable connection (in the US). But that 600K up limits my downloads anywhere else on the planet if my files are stored at my house and served by local server there.
If I store the files in the cloud, I get Google's or Wuala's or Dropbox's bandwidth to my device.
OK, so I am a fan of dropbox and I use it across many machines, (better than those on Richess) -- and, as I understand the overall issue to be, the concern is that DropBox may at some point "hand over your files" to (I assume) The Feds -- should they come knocking?
Now, I expect that for all intents and purposes the encryption/security employed by Dropbox is 'good-enough' that I dont have to worry about random-internet-user gaining access to my docs, yet I have absolutely NO illusions that ANY company will refuse to hand over my data to the feds should the feds be seeking it.
Further, I would suggest that anyone with anything they dont want the feds to know about/get their mitts on not be stupid enough to store said sensitive secrets IN THE FUCKING CLOUD
Additionally, I can understand that Drew may not be the most savvy in navigating such issues given him being a young CEO and all - and I can understand that he would want all the DropBoxians to feel comfortable with the safety and security of their data in his hands - but I would like to see a frank, real-world answer to any security claims which delineate in no-uncertain-terms exactly what level of data safety, security and encryption one may expect.
Drew may even do well as to explicitly say "We shall not refuse to hand over any of your data (and its revision history) to the Feds should they come seeking it with legal merit."
If, after such a statement people are concerned about their data going anywhere -- they should get off dropbox / implement truecrypt as stated.
Finally, a question for Drew: given this craptastic event; would Drop Box be open to much more robust file encryption tools being developed as an addon to DropBox; e.g. a third party wrapper application that allows end-to-end encryption while still allowing the web UI etc to work?
(If I misread the circumstances of the whole issue - forgive my little rant)
and, as I understand the overall issue to be, the concern is that DropBox may at some point "hand over your files" to (I assume) The Feds -- should they come knocking?
No, the concern is that Dropbox led people to believe that by use of encryption, Dropbox was preventing user files from being accessible to anyone except that user, which isn't actually true, and that Dropbox gained unearned competitive advantage because of that untruth.
Technically-savvy users who know (or more to the point, care) how Dropbox works behind the scenes may be able to figure out that user files had to be accessible to Dropbox (the "but how could they de-dupe files?" argument). Bully for them, but the fact that some people understand why an advertising claim is misleading doesn't make it okay for that claim to be misleading in the first place.
They can dedupe without needing to decrypt. Tarsnap does this. The issue is with features like being able to reset your password, downloading and sharing files via the web interface, etc.
Yes, but Tarsnap (as far as I know) only dedupes your data i.e., if I upload the same file twice it will be stored once. This is easy, because two identical files encrypted by the same key (i.e., mine) are still identical.
Dropbox dedupes across users, if Alice and Bob both upload foo.txt with identical contents (but encrypted with their own keys) the encrypted result will not be identical even though the files are. Right now Dropbox does dedupe in this situation, which obviously required unencrypted access to both files.
They actually say that they will hand over anything to the feds:
"New TOS:
Compliance with Laws and Law Enforcement Requests; Protection of Dropbox’s Rights. We may disclose to parties outside Dropbox files stored in your Dropbox and information about you that we collect when we have a good faith belief that disclosure is reasonably necessary to (a) comply with a law, regulation or compulsory legal request; (b) protect the safety of any person from death or serious bodily injury; (c) prevent fraud or abuse of Dropbox or its users; or (d) to protect Dropbox’s property rights. If we provide your Dropbox files to a law enforcement agency as set forth above, we will remove Dropbox’s encryption from the files before providing them to law enforcement. However, Dropbox will not be able to decrypt any files that you encrypted prior to storing them on Dropbox."
That said, this article is incorrect on at least one point: de-duplication does not require Dropbox be able to decrypt your files. tzs came up with this clever scheme in a previous comment: http://news.ycombinator.com/item?id=2461713
Of course even if Dropbox didn't have the keys to decrypt your files you're still trusting them (or SpiderOak or Wuala or most of Dropbox's competitors) by running their proprietary software. But I suppose people are more concerned about subpoenas and compromised servers than malicious actions by Dropbox themselves.