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.
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.
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.