I fail to see how you conclude that. Yes, they did have several glitches in the past, and no, they did not always respond as they should have.
But there are some pretty smart people working at Dropbox. What makes you think they do not have the capacity to solve security issues?
Edit: I am a pretty happy DropBox user, but I only store files there that I wouldn't really care too much if they were made public. DropBox to me is about convenience, not about security.
Edit2: I was a pretty happy DropBox user, now that I think about what having a system that is prone to "failing open" means I'm seriously thinking about closing my account. However, I'll wait and see what the "official" explanation is first.
1.) De-duplication
2.) Web access to the files.
Those are the main reasons I have come to this conclusion.
It feels a bit awkward to even refer to file-level hashing and lookup as de-duplication as it's more commonly known in block-level de-dupe.
Regardless, on documents it's probably safe to assume they get close to 2:1 compression ratio. I'd assume that the de-dupe of large binaries is a huge part of what makes running such a business on very expensive cloud-storage systems financially viable.
Would Dropbox work financially without it?
They could offer a non-de-duped version at much higher cost for the security minded, but then they've implied that the basic version is fundamentally flawed.
Just an interesting technical barriers to think about (IMO).
Here is a forum post where they admit that mobile SSL was impossible.
1. Each user has a public/private key pair. This is generated client side, deterministically from the user name and password. The public key is stored on the DBL server.
2. To store a file on the DBL server, the client encrypts the file with, say, AES256, before sending the data to the server. The key is deterministically derived from the file contents, say by SHA256.
3. The client keeps a file that contains a mapping from files to their encryption keys. This file is encrypted using a public key system, with the public key being the user's public key. It is stored on the DBL server (and no doubt cached locally on the client).
The above is sufficient for non-shared files. When you wish to retrieve a file from a client other than the one it came from, the retrieval client can grab the file/key mapping file, decrypt it using your private key, and then lookup the decryption key for the file.
For files that are to be shared with specific people, the client maintains a file for each person you share with. In this file it stores the mappings of files to encryption keys for the files you are sharing with that person. This file is stored on the DBL server, encrypted with the public key of the person you are sharing with.
De-duplication is possible in this system because when two people store identical files, they pick the same encryption key, and so the end result is the same encrypted data.
Web access is possible, as long as Javascript is allowed on the client, by implementing the key retrieval and the AES decryption in Javascript.
Note that DBL never sees the unencrypted data, and they never see the encryption key for a file in plaintext--they only see it when it is encrypted via your public key (or the public key of someone you are sharing the file with). Even if they are breached, the crackers cannot get your data. Same goes for if they are subpoenaed--they can't give up your plaintext because they don't have access.
Note also that DBL doesn't actually need your user name. All they need is your public key (at least as far as operation of the file storage/retrieval/sharing system goes--they need more for billing if you are using paid services, of course).
How would you display that data as a file or save it locally?
I guess you could do it in Flash/Java using something like Downloadify