Dropbox Head Responds To Snowden Claims About Privacy

First time accepted submitter Carly Page writes When asked for its response to Edward Snowden's claims that "Dropbox is hostile to privacy", Dropbox told The INQUIRER that users concerned about privacy should add their own encryption. The firm warned however that if users do, not all of the service's features will work. Head of Product at Dropbox for Business Ilya Fushman says: "We have data encrypted on our servers. We think of encryption beyond that as a users choice. If you look at our third-party developer ecosystem you'll find many client-side encryption apps....It's hard to do things like rich document rendering if they're client-side encrypted. Search is also difficult, we can't index the content of files. Finally, we need users to understand that if they use client-side encryption and lose the password, we can't then help them recover those files."

Comments

umm duh?

[Noah Haders]

Search is also difficult, we can't index the content of files.

umm duh, that's the point? sucks when your customers can't trust you.

Re:umm duh?

[AudioEfex]

Yeah, uh, because all "cloud" services aren't inherently ridiculous for anyone to consider secure or anything...

Re:umm duh?

[Anonymous Coward]

Hehe, I have some clients from New Zealand and they were inquiring about some of my company's cloud service offerings. I talked a bit about them but mentioned that they would be better served by hardware that they owned. I asked if they had heard of Mega and what happened to them. They said it was on the news ALL THE TIME in New Zealand. So then I said "Well then you know that law enforcement raided Mega's servers, took them, and have since refused to give all of that data back to its owners. Would you trust your data when that is one of the consequences?" They bought new servers.

Re:umm duh?

[Anonymous Coward]

me too. i was the guy who wasn't wearing pants.

Re:umm duh?

[bill_mcgonigle]

Yeah, uh, because all "cloud" services aren't inherently ridiculous for anyone to consider secure or anything...

Trust the math, not the people.

Re:umm duh?

[TheRaven64]

There are techniques that allow searching within encrypted files, but they rely on the client creating the index. You can then search the index for an encrypted search term and, if you know the keys, interpret the answer. Getting this right is quite tricky (there are several research papers about it), so he's right, but it's not impossible.

The main reason that I suspect DropBox discourages encryption is that they rely a lot on deduplication to reduce their costs. If everyone encrypted their files, then even two identical files would have different representations server-side if owned by different users, so their costs would go up a lot.

Re:umm duh?

[Charliemopps]

Yea, we use a very expesnsive cloud service that per the contract is encrypted at rest and in transit. After 5yrs I happened to have a networking issue and did a packet capture on the stream... no encryption. So we approached them... "Encryption? No, we don't do that..." We explained that it was in the contract and they HAD to do that. So after 2 months they had to move us to a "Special" server and we were encrypted. I checked the packets again and we were at least encrypted in transit. A few months later we had another trouble ticket with them. One of their techs was working on it and explained how he logged in an edited the table raw to fix it. So I asked how he could do that if the data was encrypted. "Encryption? No, we don't do that..." ugh... so now we're supposedly "really" encrypted.

The problem with cloud services is they can lie cheat and steal with your data and there's nothing you can do about it. You can't verify it, you can't test it, and if anything happens to it you wouldn't have a clue. You're entirely at the mercy of the provider and as time goes on their internal staff can turn over, competence can wane, controls can get lax, and you'll have no idea any of that is happening.

Re:umm duh?

[Anonymous Coward]

Unless the company also sells the non-cloud offerings that were purchased. In which case it's a commendable upsell.

Re:umm duh?

[hsmith]

You do realize there are several flavors of encryption, right? Microsoft SQL Server TDE is an example. You can login, perform queries, update data in any table, but all data is encrypted - it is - transparent as the name indicates.

That also ignores things like encrypted volumes, etc. Just because individual files aren't encrypted with unique keys, doesn't mean that encryption isn't there.

Re:umm duh?

[Immerman]

That can assure you that the providers can't access your data (Assuming you can also trust the software that implements the math), but it can't provide any assurance that *you* will still be able to access your data tomorrow. They could go out of business, their servers could be confiscated, etc,etc,etc. There's more to security than locking people out, otherwise instead of high-security door locks we'd simply fill the entire building with hardened concrete. Or burn it down. Much more reliable way of keeping people out.

Re:umm duh?

[Immerman]

So, when you contracted with these folks did they issue you a kilobyte-long encryption key with a warning not to lose it or your data would be permanently inaccessible? And did you have to use that key every time you stored or retrieved data with them? If not, then that's your glaring red flag that any encryption they might offer is a sham. Even if it were stored encrypted on their servers, if you can access it without supplying the encryption key that means they're essentially storing the keys in the lock to the safe.

Which is why, honestly, I'm okay with folks like Dropbox being a bit lax about security, provided they're open about it. Encryption in transit is nice if you just want to keep idle prying eyes off your not-terribly-sensitive data, and SSH provides a convenient way to implement it. But if you want real security on the stored data the *only* way to get it is if you do just what they're suggesting and exercise total personal control over the encryption. That data should be securely encrypted before it ever leaves your computers, and you are the only one who should possess the keys to decrypt it. If you want people in your organization to have easy access without worrying about encryption then establish a local proxy that will transparently handle the encryption and decryption as data flows through it to your cloud provider.

Actually that could be a great internet appliance - it could even perform indexing of the data if you wanted it to, while providing near-perfect security for *any* remote data-server offering. If anyone decides to market such a thing I want 1% for the idea - we can make each other rich.

Re:umm duh?

[nine-times]

Also, Dropbox is quite popular because of the capability to share files. So I upload a file to Dropbox, and then at some point I want to make it available to my coworker. I can either share it so that it appears in my coworker's Dropbox, or I can just create a public link and allow anyone to access it if I want.

The simplest model of client-side encryption would not allow for that kind of sharing. I'd encrypt the files with an encryption key, and then I'd need that private encryption key to be able to decrypt it. The next simplest scheme would be standard public-key encryption, which would mean that when the file was encrypted in the first place, I'd have to already know who should be allowed access, and I'd have to use their public key for encryption.

Now I'm not saying that the problem is insurmountable, but it certainly increases the complexity of the system required. The simplest solution that I can think of would be to set it up so that, when you changed the permissions on the file, it would need to be downloaded, decrypted, rencrypted, and reuploaded. If it came to that, I'd generally rather forgo the encryption, since my data doesn't really require that much privacy. The other option that I could see would be that, when you want to share your data, you pass a private encryption key to the person you're sharing with. However, that would mean that you're either giving them the encryption key to your entire Dropbox, or you're going to end up managing a different encryption key for each file.

Maybe I'm missing a simpler solution, but in the end, it doesn't seem like a trivial problem.

Re: umm duh?

[Anonymous Coward]

Symmetrically encrypt (AES) the file with a random key. Store the symmetric key encrypted asymmetrically (RSA). If you need to add access, just store a new copy of the symmetric key encrypted to the new user's public key.

Re:umm duh?

[Anonymous Coward]

Except now the police can raid their place of business and take the servers back to them ;)

Re:umm duh?

[Charliemopps]

You do realize there are several flavors of encryption, right? Microsoft SQL Server TDE is an example. You can login, perform queries, update data in any table, but all data is encrypted - it is - transparent as the name indicates.

That also ignores things like encrypted volumes, etc. Just because individual files aren't encrypted with unique keys, doesn't mean that encryption isn't there.

The data he updated was someones password. Wouldn't that concern you? ;-)

Re:umm duh?

[TheRaven64]

The anonymous poster pointed out a simpler mechanism, which is used in practice on file stores that want to be encrypted on the server. This technique also has a number of advantages. Using a symmetric cypher is generally faster than an asymmetric one and using a different key for each file is just good practice anyway as it limits the damage that certain kinds of trojan can do. If you're sharing with everyone, then you may as well just give the server the AES key and ask it to decrypt the file. If you're sharing with just a few people, then sending them a (fixed-size) key for each file is not too much overhead.

Re:umm duh?

[nine-times]

then you may as well just give the server the AES key and ask it to decrypt the file

But in that model, if "the server" has the key, wouldn't Dropbox have the key? I thought that was the whole thing people were freaking out about.

I understand what you (and the AC) are saying about storing an encrypted key on the server, and then re-encrypting the key for each new user you'd want to share with. That's a clever arrangement and I admit that I hadn't thought of it, but it still seems like it has the potential to create more complexity than most people want to deal with. It still means you need to manage various encryption keys, and we (Internet culture) seem intent on not developing a coherent system for managing encryption keys.

Re:umm duh?

[david_thornley]

Probably using something like 2ROT13. Lame. I wouldn't use anything less than 4ROT13 even for low-security stuff.

Re:umm duh?

[TheRaven64]

then you may as well just give the server the AES key and ask it to decrypt the file

But in that model, if "the server" has the key, wouldn't Dropbox have the key? I thought that was the whole thing people were freaking out about.

No, you'd have the key. If you wanted to share the file publicly, then there's no point in keeping it encrypted, so you'd provide the server with the key and it would decrypt, saving you the cost of downloading and reencrypting.

I understand what you (and the AC) are saying about storing an encrypted key on the server, and then re-encrypting the key for each new user you'd want to share with. That's a clever arrangement and I admit that I hadn't thought of it, but it still seems like it has the potential to create more complexity than most people want to deal with. It still means you need to manage various encryption keys, and we (Internet culture) seem intent on not developing a coherent system for managing encryption keys.

The client just needs one key, the RSA (or equivalent) public key. You'd need to copy this between devices, but it's relatively small (under 1KB). It's small enough to fit in a version 40 QR code quite easily, so you could set up mobile devices by displaying the QR code on your laptop screen and point the mobile device's camera at it, if you don't have any sensible way of transferring files between devices. The client then has to download the file and the associated key, decrypt the key with the locally-stored key, and then decrypt the file, but that's not something that's exposed to the user.

Re:umm duh?

[nine-times]

If you wanted to share the file publicly, then there's no point in keeping it encrypted, so you'd provide the server with the key and it would decrypt, saving you the cost of downloading and reencrypting.

Right, so Dropbox would have the key. Part of my point is that an awful lot of people use Dropbox for sharing, at times not terribly concerned with who is being given access, and so all this freaking out would be unfounded for that subset of cases.

The client just needs one key, the RSA (or equivalent) public key.

Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encrypted file and the encrypted key to another user, knowing that it will need that users private key to decrypt.

So right there, you have to manage private keys per user. You have to manage a unique symmetric key per file, and you have to manage encrypted keys per file per user. If you have a hundred users and thousands of files, that's already adding up to a lot of keys. It also means that they's a lot more that can go wrong, compared to a simple case of storing unencrypted files.

Of course, a lot of this can be managed with software. Still, that adds a lot of complexity to the software. I would imagine the whole Dropbox syncing process would be slower and more processor/storage intensive, since it would need to cache the encrypted files and encrypted keys, decrypt all the keys, decrypt all of files, and then store the output files on the storage. Or would the files be decrypted on the fly, on access?

I'd imagine Dropbox doesn't particularly want to add all of that complexity, and users wouldn't want the additional overhead (slow syncs and higher resource usage). Most users can't be trusted with a single private encryption key. Oh, and on top of all that, it would also mean that Dropbox users would probably lose features, since Dropbox would be losing the kind of access that would allow them to easily index and process files, and Dropbox wouldn't be able to do things like deduplicate the data.

Don't get me wrong. I like the idea of encryption. I also think it's a bit silly to sit back and demand that Dropbox encrypt everything when we (the internet society/community), haven't even developed good standards and infrastructure for dealing with encryption. We haven't even made SSL cheap/easy enough to enable anyone setting up a website to use it, and a lot of our traffic is going unencrypted. I'd rather start with someone building a system that makes it easy for everyone to have their own private/public keyset, and use it ubiquitously instead of having to create passwords on every individual site, only to have half of the passwords pass through the Internet in plain-text. Given that, I think it'd be silly to think that Dropbox is the big danger to your security.

Re:umm duh?

[TheRaven64]

Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encrypted file and the encrypted key to another user, knowing that it will need that users private key to decrypt.

Every time you upload a file, you generate a random symmetric key. You encrypt the file with this key and the key with your public key. If you want to download the file, you get the file and the encrypted key and then you decrypt the key with your private key and then decrypt the file. When you create the account, you upload your public key.

When you want to share a file with everyone, with no access control, you download the encrypted key, decrypt it, and provide it to the server. The server can then decrypt the file.

When you want to share a file with a limited set of users, you download each of their public keys (which you can cache in the client) and the encrypted symmetric key, decrypt the key, and then encrypt it once for each user. They will then only be able to access it with their client.

I'm not sure who you're 'we' as in 'internet community' is. We do have standards and off-the-shelf libraries for everything required to implement this and others have done so in the past (one of my colleagues during her PhD did back around 2006, to give one example, others have implemented more complex and flexible schemes more recently). Note that this is the simple textbook scheme for doing this kind of system. It's been implemented before and doubtless will be again. If you check the research literature then you'll find more interesting schemes.

The only problem is if you want to be able to access it from the browser, without some kind of plugin (Google actually does compile OpenSSL with Emscripten to do ASN.1 parsing, but I wouldn't recommend using it for encryption).

Re:umm duh?

[nine-times]

We do have standards and off-the-shelf libraries for everything required to implement this

Yes, exactly. There are libraries available so that you can create your own solution for encrypting files and managing the keys. You can do it, and I can do it, and some other guy can do it, and if anyone is unlucky enough to want to use all of the services we create, then he can have several implementations of what is essentially the same encryption scheme with multiple different methods of managing the many associated keys. Some of the key management will be made transparent by having it automatically managed by software, or maybe it won't. Who knows, because we're all rolling our own solution.

And maybe, just maybe, if we all do things the right way, he can use the same private/public keys for all of the solutions. Except that we don't know what the "right way" is because while there are libraries for the encryption algorithms themselves, there's no cross-platform standard for actually implementing the entire system. Much more likely, he'll be able to use the same keys for 6 out of 10 services if he's a programmer or expert sysadmin, and can recompile of some the open source libraries with the appropriate switches to store data in a specific location... or whatever. It depends. Who knows.

This stuff just isn't going to work until someone actually works out an entire system, and there's a consensus within the community (users and developers on the internet) on the proper implementation. Until then, there will be a hodge-podge of silly solutions that users will be hesitant to use, with good reason.

Yes, I understand that you won't even be able to see the problem I'm indicating.

If you check the research literature then you'll find more interesting schemes.

That's part of the thing, I don't want more "interesting" schemes. I want the internet to agree on one very dull scheme. How to I enable a user, a user who is essentially a moron when it comes to computers, to encrypt all of their data and all of their traffic without any risk of losing data when they lose their private keys. Come up with a single scheme, get Google and Dropbox and Microsoft and everyone else to agree to an implementation that will work the same way across all services. Make it as common as SSL, but make it free. Give me a complete software solution that lets me encrypt my files on Dropbox, Google Drive, OneDrive, let's me verify my identity on SSH connections, as well as sign/encrypt my email. Let me store that key once per machine, securely manage it across machines, be able to revoke it, be able to handle a complete loss of that key. Make this simple enough that I can do it even though I can't configure an IMAP/SMTP mail account. Make the whole thing virtually free.

When you've figured that out, that is when we can have ubiquitous encryption on services like Dropbox. Until then, you're just adding complexity and nightmares to whoever has to manage these things.

Re:umm duh?

[TheRaven64]

Everything you ask for exists. The reason that Google, Microsoft, and Dropbox don't use them is that their entire business model depends on differentiation. If you could connect to their services with any third-party client that also worked with a server that you set up yourself and with their competitors' services, then their hold on the market becomes very tenuous. You're searching for technical solutions to business problems.

Re:umm duh?

[nine-times]

You're searching for technical solutions to business problems.

Sometimes there are technical solutions to business problems. But my point from the beginning is that it wasn't simply a technical issue of whether we can encrypt things. It's whether we, the users and developers on the Internet, can agree on a set of standards that make encryption easy for people who don't understand encryption and can't be trusted to figure it out.

You keep pointing out that we theoretically could do all the things that needed to be done. I'm trying to point out that still, we keep not doing it. Sure, there are libraries for encrypting things, but what I'm trying to drive home is that encryption isn't the problem. The problem isn't "I need to encrypt a file," but "I need to be able to store my files so that they're secure, accessible, easy to find, easy to share, and nearly impossible to lose. If it's properly implemented, encryption can help with the "secure" part, but it can also easily hinder the rest. Until you can develop a complete solution that solves the entire problem while transparently encrypting files without causing other problems, encryption doesn't help to solve the problem.

Our stuff is encrypted!!!!

[Y2K is bogus]

With the keys we readily hand over when warranted.... o_O

Re:Our stuff is encrypted!!!!

[Anonymous Coward]

I wouldn't expect anything more than that from services that are aimed at businesses, and I think you've got to be an idiot if you view a free (or dirt cheap) storage service like Dropbox as anything other than temporary space some stranger's letting you use for a while. You've got to expect that you can't rely on the data to persist when you want it, and that it'll always be there if the government or hackers or anyone besides you wants it. I don't really have a problem with that. At zero dollars, it's been handy to have around and their API is probably the simplest and best of the cloud services I've used (even though their handling of file-type-based app permissions is bizarre).

Re:Our stuff is encrypted!!!!

[Gr8Apes]

With the keys we readily hand over when warranted.... o_O

Who needs a warrant? Just a couple of bucks for our "anonymized" (wink wink) data.

Re:Our stuff is encrypted!!!!

[Mr 44]

http://xkcd.com/1150/

Duh

[backslashdot]

Dropbox has Condoleeza Rice on its board of directors. If anyone remembers, she was Secretary of State and also the president's National Security Advisor during the Bush administration. She basically allowed torture, and is responsible for Guantanamo. She had no problem with torturing people without even doing a basic check to see if the person being tortured was guilty of the crime he was being tortured for. And you want to talk about spying? She was part of the administration that developed the PATRIOT Act. The justification being "it's ok to spy on foreigners" .. Oh and we can DECLARE you a foreigner without any due process by making you prove your Americanness. She was cool with torturing foreigners without giving them any sort of due process, so why would you assume that she wont torture citizens if she was scared into doing so? We already know she doesn't think people need privacy.

Re:Duh

[viperidaenz]

It's ok Pluto, I'm not a planet either :(

Re:Duh

[rsborg]

Why is this comment rated so low? If anything, having such a politically invested person on the board of directors really does say something about Dropbox and their views on privacy and security (yes, I do think the same about Apple and Al Gore - his values did seem to align with the company's).

Ever since 1Password moved to iCloud sync, I've stopped using Dropbox for even stashing an encrypted file. For everything else there're more targeted cloud services.

Re:Duh

[operagost]

Good thing she's not a Democrat, or we'd all be calling you racist and sexist.

Re:Duh

[towermac]

Dude, the election is long over, and your guy won.

"She basically allowed torture"

Huh. I remember Bush being in charge during that time.

"is responsible for Guantanamo"

I don't even know what to do with that.

"torture"

I guess she held the garden hose eh?

"She was part of the administration that developed the PATRIOT Act."

the Act passed the House 357 to 66; passed the Senate by 98 to 1. But somehow her fault..

People hate on her because she's a black female Democrat that switched parties, which is not allowed. That racist crap really pisses me off. The fact is; she's a badass, and the only thing she did wrong was to come of age at the same time Bush got elected.

Re:Duh

[DocSavage64109]

I wonder if some of that is due to being among the first black people in a position of power. She can't really rock the boat to much and ruin things for future black politicians, so she has to be a bit conservative. I think Obama is doing much the same thing.

Re:Duh

[Anonymous Coward]

Ever think maybe no one is calling it sexist or racist because it doesn't contain any particularly remarkable sexist or racist content, whereas perhaps the remarks you've heard referred to as sexist or racist might have contained such content?

Re:Duh

[backslashdot]

Nobody that resorts to such a cowardly and fear driven act as torture is a badass. A badass wouldn't be so scared of the consequences of not torturing someone that they would be willing to give up their humanity. Only fear, paranoia, and revenge can drive someone to torture another.

Re:Worst Response of all Time

[Anonymous Coward]

It's not stupid; it's just a fact. Obviously they can't do any of that crap if they can't decrypt your data, but that's fine by me.

Re:Worst Response of all Time

[AudioEfex]

It's not stupid; it's just a fact. Obviously they can't do any of that crap if they can't decrypt your data, but that's fine by me.

Exactly. Gotta love the knee-jerk, I can't have a logical thought because I'm just so ready to rant about "the man" bullshit. Especially since it sounds like it's coming from someone who doesn't even use or understand the service.

Dropbox is file storage, plain and simple. I use it to make a few music files and some reading material available across my devices. That's it's main function, to store/share files.

All that other shit he is talking about that encryption won't work with is all fluff and ancillary stuff - I name my files properly, for example, so I don't need them to search within them for me. The service works just fine with encrypted files - you just can't use the fancy doodads that you don't really need anyway.

I applaud him for being honest - if this was certain other companies they'd be telling you "oh trust us. It's secure!" He's being honest - it's a dumping spot for files, if you want encryption, BYO.

Christ some of the folks around these parts don't know their heads from their asses - use the words encryption or privacy and they don't even listen or understand wtf is being talked about they just automatically jump to tired fear mongering rhetoric. Just like the folks who take rifles strapped across their backs to Starbucks - I want to say, WTF are you so scared of? And if you do have something to be scared of - stay the fuck home, or in this case, don't be a complete retard and use a "cloud" service to begin with.

Cloudy, chance of rain

[AndyCanfield]

Dropbox is cloud. Cloud is a remote hard disk. My hard disk has nothing to do with privacy; anyone who can SSH into my computer can read my hard disk. Put that hard disk on the Internet, in "the cloud", and the same thing applies, anybody logged in to the Internet can read your dropbox. Hey, I thought that was the PURPOSE of Drop box, to share files. If you want privacy, burn a DVD and hand it to the guy.

For me, my notebook has a 1TB hard disk. I have a web site I control. Yeah, my web site is hostile to privacy; that's the whole purpose of a PUBLIC web site. I had a "Dropbox" and dropped it.

Re:Cloudy, chance of rain

[martin-boundary]

How is that insightful? You've completely missed the whole point of privacy laws. In law, your hard drive in your computer is yours, and it is not public unless you go out of your way to make it so. In particular, anyone who uses ssh to access your hard drive breaks the law, unless you've specifically authorized them to do so. Lots of people, some slashdot readers, have gone to jail for doing just that.

Also, your hard disk, in your computer, in your house isn't searcheable by law enforcement unless they have a warrant. So keep your stuff at home, and you'll be better off than leaving it on Dropbox (*).

(*) I can see you're unconvinced. Let me spell it out for you: if your file is on Dropbox, then a properly worded warrant needs to be served to Dropbox, and they'll allow searches and copies of anything their hard drives contain. Including your file, your neighbour's file, everybody's files. If everybody keeps their own files at home, then a warrant needs to be served to you, to see your files, but it won't work for your neighbour's files. Another warrant needs to be served to the neighbour to see his files. And it won't work for everybody else. A warrant needs to be served individually to everyone, just to get the same access that Dropbox can give with a single properly worded warrant.

Re:Cloudy, chance of rain

[HuguesT]

Exactly. Also the NSA doesn't even need warrants. How convenient for them that everyone is leaving these fine files in the same place for them to search...

Re:Cloudy, chance of rain

[Threni]

> Let me spell it out for you: if your file is on Dropbox, then a properly worded warrant
> needs to be served to Dropbox, and they'll allow searches and copies of anything
> their hard drives contain.

Let me spell it out for you. You're safe outside. If anyone attacks or robs you, they'll be breaking the law.

Re:Cloudy, chance of rain

[nine-times]

My hard disk has nothing to do with privacy; anyone who can SSH into my computer can read my hard disk.

Really? Can you give me the IP, login, and password? I'm curious. I normally set up SSH in such a way to prevent any ol' person on the Internet from logging in, but that's just me.

anybody logged in to the Internet can read your dropbox

Maybe if you share your whole Dropbox publicly, and then pass the link around. But as for me, I usually don't do that. In fact, my company Dropbox is set up so that I can't even share files with people outside of my company. I guess Dropbox can see my data, but that's not the same as "anybody logged in to the Internet".

How is this insightful?

Re:Cloudy, chance of rain

[david_thornley]

Which is why I wouldn't put anything on Dropbox that I wouldn't want the NSA or FBI to know about. Being traceable publicly is not a problem for me; I just want the ability to do less traceable things when I want to.

Re:Worst Response of all Time

[Kardos]

So, you would have preferred a positive sounding statement indicating that they are aware that some users have privacy concerns and a vague reference to ongoing efforts to address these concerns?

I didn't find that response "worst of all time". It came across as lacking in the bullshit department, almost refreshingly so, actually.

Re:Worst Response of all Time

[Anonymous Coward]

This has to be one of the worse responses of all time. I have no idea how well Dropbox protects their users privacy, but the suggestion that if users do not trust them they can use their own encryption, but then none of their features will work is just stupid.

A lack of Indexing and searching of your encrypted containers is obvious, but not nearly as obvious as your lack of comprehension. TFA clearly said some of the features will not work when client-side encryption is used. No one claimed the service would break completely.

Trust No One = TNO

[Streetlight]

Steve Gibson's mantra: TNO. If the host has your encryption password/key, then they can't be trusted. If you don't believe that, ask Snowden's email provider, Lavabit's founder Ladar Levison: http://www.wired.com/2014/04/l...

Re:Computers 101

[Anonymous Coward]

No, they don't. If they did they wouldn't expect a fucking cloud storage service with any sort of private information.

You have to necessarily be a braindead buttfuck retard to do that. I use Dropbox all the fucking time but I don't expect a damn bit of anything I put on it to be private. It's a way to move shit from Point A to Point B and nothing more. Storing private data on it is a sure sign that you should have been aborted.

No big deal (except the encryption part)

[scottbomb]

I don't need them to do "rich document rendering" (whatever the hell that is) nor do I need them (or anyone else to) index the contents of my files. All I want is for someone to STORE the shit and keep it synced between all my machines. Dropbox does this very well.

As for encryption, I don't have time for that nonsense. Anything sensative such as financials is kept locally on my own server or burned to a DVD and put in the closet. I couldn't care less if someone gets a hold of my vast collection of pictures and documents. It is private, but not going to hurt me if someone at the NSA starts snooping around.

Re:No big deal (except the encryption part)

[SuluSulu]

You might consider checking out Spideroak.com as they claim to not store your password on their servers so that it is impossible for them to decrypt your files without you. Also they have a decent synchronization client for all major OSs. Disclaimer: I am not affiliated with Spideroak, just a user.

Re:No big deal (except the encryption part)

[rioki]

You know there is a web interface to Dropbox too? People expect to read their documents, like word or PDF right there online. To do this the service must index the files and read them. Obviously if you encrypt the files, this can not be done.

I use Dropbox as my offsite backup of sensitive information and I trust the information to be safe. Simple, I encrypt the tar-ball with symmetric GPG. But then again I can only download the file vie the web interface if I wish and not view the contents online... buhuhu

Re:No big deal (except the encryption part)

[DocSavage64109]

Well, maybe with Dropbox installed such people now have plausible deniability.

Re:No big deal (except the encryption part)

[chihowa]

If you use their web interface, they will store your password on their servers. Be aware of that.

Also, your account password is the the key used to encrypt your data (easy to verify: accessing your data on a new device only requires your account password). They use PDKDF2, which expands the password into a larger key, but (obviously) doesn't add any entropy to that already present in the password. Choose your password wisely.

That password is also used to access the billing, etc web interface, so they do keep at least a hashed copy of your password on their servers.

As with any closed source and opaque solution, you shouldn't depend in any way on unverifiable claims. They could now, or at any time in the future, store your passwords. You're better off handling your own security than trusting magic black boxes.

iDrive has the same problem

[Animats]

iDrive, which is supposed to be a remote backup service, has a similar problem. They used to be a honest remote backup service, with client-side encryption. (They didn't protect the client password very well on the client machine, but at least the server didn't have it.) File contents were encrypted, but filenames were not, so you could look at logs and the directory tree on line. Then they came out with a "new version" of the service, one that is "web based" and offers "sharing".

For "sharing" to work, of course, they need to know your encryption key. They suggest using the "default encryption key". Even if you're not "sharing", when you want to recover a copy of a file, you're prompted to enter your encryption key onto a web page. The web page immediately sends the encryption key to the server as plain text, as can be seen from a browser log. Asked about this, they first denied the problem, then, when presented with a browser log, refused to answer further questions.

They try real hard to get their hands on your encryption key. After you log into their web site, a huge pop-up demands your encryption key. Without it, some of the menu items at the top of the page still work, and with some difficulty, you can actually find logs of what you backed up. You can't browse your directory tree, though.

It's possible to use the service securely (maybe), but you have to run only the application for recovery, and never use the web-based service. They don't tell you that.

This isn't a free service. I pay them $150 a year.

Re:iDrive has the same problem

[jhaar]

You're still paying money with those concerns?? Just move your money (and data) to SpiderOak and be happy: good client-side crypto can be done properly.

Re:iDrive has the same problem

[Anonymous Coward]

And Spideroak gives you a closed binary to run on your endpoints, and you quite happily type your password into that. Uh-huh.

Spideroak are just another vendor saying 'trust us not to have been served an NSL' and trust us not to capture your key with the client software if served an NSL/warrant.

Once the spideroak client is open and audited, perhaps at that point their marketing about a secure server architecture makes a difference.

Re:iDrive has the same problem

[chihowa]

Just move your money (and data) to SpiderOak and be happy: good client-side crypto can be done properly.

And you're basing that on what, exactly? Marketing claims. And in reply to a post about how marketing claims ended up not being true in iDrive's case.

Re:Just wow..

[Anonymous Coward]

You must not have much exposure to bullshit.

This is actually a genuine and honest statement that is frank and straightforward.

Syncplicity solves it!

[GWBasic]

Syncplicity lets enterprises store files on their own servers, with an extra layer of authentication that prevents Syncplicity staff from getting to the files. It still allows for access to these files through a web browser. When enterprises use single-sign-on, users don't even realize that they're authenticating multiple times.

This is a very hard problem to solve for consumers, though. Most people don't have the time to set up their own cloud servers.

Re:Just wow..

[Anonymous Coward]

That is the lamest explanation for a deficiency in service I have ever heard from a fellow fluent in the language du jour.

You misspelled layman. Sometimes you nerds often forget that services like Dropbox have gone mainstream, and therefore take an extra helping of "for dummies" ladled on top of the usual rhetoric. This isn't some *NIX SFTP server you download and configure manually in a VM. Dropbox is about as easy as Facebook to set up. Therefore, when coming forth with a form of CYA explanation regarding a deficiency, one must be able to speak to the entire audience.

That said, I promise 80% of Dropbox users reading the words "developer ecosystem" will respond with a stare more blanked out than a Kardashian at a cell phone kiosk. Even this explanation wasn't layman enough.

Re:Worst Response of all Time

[cold fjord]

Christ some of the folks around these parts don't know their heads from their asses - use the words encryption or privacy and they don't even listen or understand wtf is being talked about they just automatically jump to tired fear mongering rhetoric.

I hadn't noticed.

Re:what's new

[Opportunist]

Try to convince a Manager hellbent on joining "The Cloud" and you know the answer is no.

For a chuckle, have him explain what "The Cloud" is before you do. At least it provides some entertainment before you try to convince him he's about to sink his business.

I appreciate him saying that.

[ddt]

Perhaps "hostile" was unfair, but I appreciate that he said made it sound shocking. I am shocked when I learn people store secret docs unencrypted on Dropbox. Then they are then shocked when I tell them Dropbox is insecure. There should be a lot less shock all around.

Re:I appreciate him saying that.

[Immerman]

It would be nice if Dropbox et. al. included prominent disclaimers to warn the less-savvy (i.e. most of their user base) that data stored on their servers is insecure, but given the number of shady competitors who claim security without delivering anything better I suppose I can understand why they don't.

Sensible response

[Craig Ringer]

That's an accurate and sensible response.

In fact, 3rd party client encryption tools might be better than built-in support by Dropbox. They can be produced outside the USA by companies or individuals unaffiliated with DropBox and potentially harder to pressure into backdooring the software in an update.

I'll stick to SpiderOak personally, despite the awful transfer speeds and somewhat clunky usability, because I just want a remote store that stores my gibberish bytes and gives me the same gibberish bytes back later.

Alternatives

[fuzzyf]

I tried using SpiderOak, but it was a bit too slow for me atm. What I really needed was a off-site backup, so I ended up with Amazon Glacier with client side encryption. Can't beat the price :) I have dropbox too, and it's ok for it's use. Just have to realize that everything you upload to them is not private anymore. I wish more services did secure by default and option to reduce security for wanted features.

And deduplication will not work anymore

[greatpatton]

There is also a strong argument for company like Dropbox to avoid or at least not encourage too much client side encryption: deduplication. If deduplication is no more working, it will considerably increase their storage cost, which the core of their business.

I think people are missing the point

[Anonymous Coward]

One of Dropbox's features is the ability to access your Dropbox files through your web browser. Which can be very convenient for some people.

Obviously they couldn't do that if your account was encrypted to an extent that even Dropbox couldn't decrypt it.

I don't understand people complaining about a service that is up front about offering more convenience than security (not that Dropbox is insecure, they just trade off some security for convenience).

If you want a service that offers more security than convenience, then don't use Dropbox. Duh.

Re:I think people are missing the point

[Captain Hook]

Use the web interface to download the file, then decrypt with a local copy of the encryption tool/key.

What they mean is they can't render a document on the web interface.

Re:I think people are missing the point

[Immerman]

Sure they could, it would just require that you provide your encryption key to the web app before transferring files. Not quite as convenient, but eminently doable.

Re:I think people are missing the point

[Immerman]

I never said I don't like them - I don't have much use for their services personally, but they seem quite handy for those who do. I was simply correcting the statement:

>One of Dropbox's features is the ability to access your Dropbox files through your web browser. Which can be very convenient for some people.
>Obviously they couldn't do that if your account was encrypted to an extent that even Dropbox couldn't decrypt it.

Because obviously they could do so if they wished to, it would simply involve inputting your encryption key into the web interface. Hell, they could even generate a (crappy) encryption key from your password and keep the current level of convenience - so long as they don't store the password anywhere (which is a crappy security move anyway - that's what salted hashes are for) it would at least make your data a lot more inconvenient for anyone else to access.

Re:I think people are missing the point

[Immerman]

Care to place a bet on that? Shouldn't be so terribly difficult to write an en/decryption routine in javascript. A bit slow perhaps, but perfectly functional.

We should add our own encryption???

[DrXym]

Hi Dropbox, stop blaming users. You are in the strongest position possible to offer encryption in Dropbox because it's your software. You know the triggers that cause files to be exchanged. You know the optimal way to minimize network traffic. If you can send and receive files, then why can't you also encrypt / decrypt files in this step? This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client. This encryption could also scramble file names and break up large files into parts to obfuscate their size.

Yes you'd have to warn the user that a protected folder means exactly that and there are restrictions on what you can do with it, e.g. access in some dropbox clients, web browsers, sharing to others. People will get it.

Even better, this encryption / decryption could be thrown open as a pluggable API so 3rd parties could write their own encryption protocols to whatever personal or corporate standard they desired. For transparency the aforementioned passphrase encryption could even be supplied for review.

Same goes for Skydrive, Google Drive etc. There is no excuse for not offering encryption. Not that I'm in the tinfoil hat camp to think this is to facilitate monitoring (although it does). More likely it's because these cloud storage servers use file hashing to spare themselves the bother of storing 1,000,000 copies of the same file. It still sucks though and even if the option is off by default, encryption of at least one folder should be provided.

Re:We should add our own encryption???

[coofercat]

You realise dropbox is free, right? Why should they do something expensive like offer encryption on a service that is (a) free, and (b) for sharing files. Sharing's hard if your stuff is encrypted, and sharing is the source of most of Dropbox's value.

If you want encryption, then fine, do it yourself. You obviously know that your stuff won't be indexable or shareable so won't be calling for support or slagging Dropbox off online when you find indexing and sharing not working.

There's room to suggest Dropbox should offer a pay-for encrypted service. The thing is, no matter how well they do it, it'll always be vulnerable to government interference, and it'll never be fully trusted anyway. BYO means no government interference and trust *for the relatively small number of people who care* without raising the costs too much for the multitudes who don't.

Re:We should add our own encryption???

[Immerman]

There absolutely are several reasons for not offering encryption. Some of the big ones that leap out at me:
1) Most users are technically incompetent, and when they lose their encryption key they'll be prone to blaming Dropbox for the loss of data.
2) Compression and data de-duplication between users is effective on unencrypted data, not so much on white noise. Make encryption standard and plan on being able to offer only a small fraction of the capacity at the same price point.
3) If you want real security you have to assume you can't trust anyone except yourself, and would have to do your own client-side encryption using trustworthy software anyway. It really is the only rational choice where security is concerned.*

*Even among the services that offer client-side encryption, a dismaying number discretely keep their own copy of your encryption key - at which point the encryption provides little more than an inconvenience to anyone trying to access your data - if they can get access to your encrypted data on the remote servers, they can probably also get access to the copy of your key stored there. And unless the client-side software is open source and audited by multiple independent parties before rolling out every update you have to assume that *every* provider is making that copy.

Re:We should add our own encryption???

[trawg]

You realise dropbox is free, right? Why should they do something expensive like offer encryption on a service that is (a) free, and (b) for sharing files. Sharing's hard if your stuff is encrypted, and sharing is the source of most of Dropbox's value.

I'm a paying Dropbox customer.

I would love a feature that lets me client-side encrypt my files before they go to their server; one where the keys never left my machine - being aware that if I lose them, I lose all my data.

I would want the client software to be open source though and suspect that might not be in their interests.

Ultimately though I think they've made a conscious choice to not offer a feature like this not because they don't want to or because NSA, but because they see it as a support nightmare.

I tried a few of the alternatives that do client side encryption - Wuala and SpiderOak. I found them completely painful compared to the simplicity and elegance of Dropbox.

Re:We should add our own encryption???

[DrXym]

You realise dropbox is free, right?

Basic Dropbox is, none of the other options are. And besides, why is that an excuse? If they can encrypt data as they send it, and as they store it on the cloud, why is it impossible to encrypt it on the client, or provide an API to allow a 3rd party to encrypt it? Furthermore, as it is the paid service that pays their wages, why aren't they implementing a feature that customers, particularly corporates would pay for and which would enhance their reputation for secure storage?

If you want encryption, then fine, do it yourself. You obviously know that your stuff won't be indexable or shareable so won't be calling for support or slagging Dropbox off online when you find indexing and sharing not working.

Well that's a stupid argument right there. I wonder if car companies apply it too - well if you want an airbag in your car why don't you install it yourself? Just because a single individual has the technical wherewithal to implement something doesn't excuse the company for not implementing it in the first place, particularly when it is a feature that many people want.

There's room to suggest Dropbox should offer a pay-for encrypted service. The thing is, no matter how well they do it, it'll always be vulnerable to government interference, and it'll never be fully trusted anyway. BYO means no government interference and trust *for the relatively small number of people who care* without raising the costs too much for the multitudes who don't.

No it won't. The point of a well designed client side encryption is Dropbox simply have no idea what they are storing on their servers. Government can interfere until the cows come home but Dropbox have no idea what is in those files.

Re:We should add our own encryption???

[DrXym]

1) Then you put a big warning on the feature making it clear that the user must remember their passphrase. You could also make it only work on a folder explicitly called Protected to hammer this home.

2) Most encryption schemes compress before encrypting. So nothing is lost there. As for de-duplication, I don't see that being a huge concern because a) even if encryption is an option most people won't use it and b) When TFA has dropbox's head honcho saying "We think of encryption beyond that as a users choice."

3) That argument doesn't really fly at all. Security is not an all or nothing thing. Different security serves different purposes and can mitigate different attacks. e.g. encrypting data client side means that if Dropbox's servers were compromised or their users database was stolen that my data is still secure.

Re:We should add our own encryption???

[TangoMargarine]

1. Dropbox implements server-side encryption.
2. NSA/TLA drops by.
3. Dropbox gives them your keys.
4. No profit.

You are utterly failing to understand the issue. Have you been living under a rock for the last several years?

Re:We should add our own encryption???

[Immerman]

1) Rule #1 of UI programming - essential messages will never be read. A "protected" folder might work though. You could also potentially offer an offline key storage service (with heavy validation for retrieval) so that those who are willing to trust you can at least get protection from anyone *else* accessing their data.

2) you may have a point

3) Umm, exactly? You seem to be agreeing with my point. Client-side encryption offers a shot at real security, server-side mostly only offers a minor inconvenience to a competent hacker, and none at all against an NSL, bribery, etc. Same for client-side encryption where they keep a copy of your key on their servers. Sure it'd be nice if they had some server-side encryption to keep at least the script-kiddies at bay, but how big a threat are those, really?

Re:We should add our own encryption???

[marbux]

I agree that Dropbox's client should handle encryption/decryption on the client side. The fact that they don't offer that option and the disclosure that they were next on the NSA's todo list sent me looking for a more secure alternative. I'm now using Wuala for file sync. All encryt/decrypt actions happen in the client other than the SSL return trip. The client runs on the Java JRE, and presents itself to the host system as a virtual drive, when logged into the client. If not logged into the client, the virtual drive is not available. Passwords are encrypted on the server side, so if you forget your password, you're S.O.L. on regaining access using that account. They can't help you. First 5 GB file storage is free; charges for more storage are less than Dropbox's. Furthermore, it's a Swiss company with its servers located in Switzerland. That nation is far enough along in the process of becoming an EU member nation that the E.U. data privacy rights apply (far more protective than in the U.S.), but the exceptions to the EU privacy rights do not yet apply, although that's a window that will close at some point. File load/save times on the virtual drive are a bit slow (I've Java JRE, after all), but not ridiculously so. File syncs are faster than Dropbox's, at least on my systems. I don't know why. I like it a lot. I'd rather not run my own VPN and leave a server running at all times when I'm away from home. All I'm after is portable file sync. I don't need to search the files on their servers nor do I need a web interface. If I'm using someone else's system (rare event for me), it's easy enough to download and install the client temporarily unless the system blocks installation of a Java app. Wuala does have a few extra bells and whistles, but I haven't used them so far. Generally speaking, I'm boycotting web services that are susceptible to orders issued by a U.S. judge because they are being insufficiently aggressive about clipping the government's digital snooping powers. The more they are boycotted because of it, the more incentive they have to spend more on lobbying and litigation.

Re:We should add our own encryption???

[DrXym]

Read my original message. I was never pushing for server side encryption. As far as I'm concerned server side encryption is pretty worthless. It might stop an employee stealing data without authorization but it doesn't stop the government, or any 3rd party armed with a subpoena coming in and taking your stuff. But DropBox has fat clients. They can implement encryption on the client side before it ever reaches the server. They could also make the encryption pluggable so somebody with a hard token, or a fingerprint scanner, or some weird ass corporate policy could plug their own solution in. It doesn't mitigate all attacks naturally but it does protect users from DropBox being compromised, or being served with some narrow or broad demand to access certain data.

Re:We should add our own encryption???

[DrXym]

"This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client." You are utterly failing to read my post. I didn't say server side encryption.

Re:We should add our own encryption???

[TangoMargarine]

Then they aren't actually "offering strong encryption." They're just offering an endpoint for the user to hook into? How is that different from what they're already doing?

Re:We should add our own encryption???

[TangoMargarine]

Personally, trusting the closed-source Dropbox desktop client to do your encryption for you and not ever transmit your keys back to the mothership for the inevitable NSA demands is more trust than I'm willing to give. And you remember the hullabaloo where it turned out that their desktop client auth was horribly, horribly insecure?

Just make a dynamic TrueCrypt volume.

Re:We should add our own encryption???

[DrXym]

Please read what I wrote. Dropbox could offer to encrypt a protected folder. By default that could be passphrase based encryption. The encryption could be pluggable to allow other forms of encryption. The passphrase based encryption source / algorithm could be submitted for review.

Re:We should add our own encryption???

[DrXym]

False security. If you're paranoid that Dropbox sends your password back then you shouldn't be using it at all. Period. It wouldn't be hard for them to infer that the frequently changing, fixed size random file they were stashing was a truecrypt volume and for them to enumerate the mount points to see what was in it.

Re:We should add our own encryption???

[TangoMargarine]

It wouldn't provide much in the way of plausible deniability, but please tell me about how easy it is for them to mount it without the keys. There definitely wasn't a federal case with some guy from South America where the FBI admitted after a year that they couldn't crack his encryption.

enumerate the mount points to see what was in it.

Not quite sure what you mean by this...as a dynamic file, it's only going to have one "mount point," and while encrypted at rest it's more or less (less) indistinguishable from entropy except for the headers.

Re:We should add our own encryption???

[Samizdata]

The problem with this is that Dropbox states they may use already stored copies of a file to provide access to data when possible. The encryption would block this deduplication by making a different version of the file among users. (Just a note - I primarily use Dropbox to make non-secret file duplication among various machines and OS sessions easy. Anything important, I encrypt by hand.)

Re:We should add our own encryption???

[Samizdata]

Basic Dropbox is, none of the other options are. And besides, why is that an excuse? If they can encrypt data as they send it, and as they store it on the cloud, why is it impossible to encrypt it on the client, or provide an API to allow a 3rd party to encrypt it?

One of the things I love about Dropbox is that I use it to sync between Windows and Linux machines. As soon as you add this functionality via API, I can pretty much guarantee you the Linux side will end up with no or non-compatible functionality (unless I was WAY lucky). So I still wouldn't end up using it. So there's that....

Re:We should add our own encryption???

[david_thornley]

I like my idea for client-side encryption. I get some crypto software from a third party, preferably open source, and I encrypt stuff and then put it in the Dropbox folder. If I'm feeling paranoid, I get a cheap computer, don't connect it to anything else, and use USB sticks to move plaintext in and ciphertext out.

I wouldn't trust any feature from the vendor to do encryption and decryption on the fly. If I'm going to be cautious and secure, I'm going to do it right.

Re:Worst Response of all Time

[Anonymous Coward]

You've verified that the source _available_ doesn't have backdoors. How do you know that what's actually running on their servers doesn't?

If you don't want to have to trust someone, then you have to do everything yourself.

Otherwise you have to live with giving up some degree of certainty in exchange for a little trust.

owncloud?

[0xdeaddead]

why not roll your own? a VPS is too cheap these days...

Re:owncloud?

[AHuxley]

Yes get the OS to create its own files to move up everyday. All the good aspects of the cloud, nothing to see but encrypted files your OS understands and can recreate, search. Storage space is all you need.

Re:own cloud

[davmoo]

Yep, that's exactly what I do. I know exactly what's going on with my data, and if its insecure, I know its my own dang fault.

Re:what's new

[Anonymous Coward]

Sometimes you can't reason with folks who just want the ``supervised cloud migration'' or ``moved the company into the cloud'' etc., next to their accomplishments---especially if all the other managers are doing it too.

And yes, cloud is seen as this mythical thing that will fix all IT problems. Low on disk space? Cloud will fix it. Databases are slow? Cloud will fix it. Not enough hours in the day? Cloud will fix it.

Problem is that to an extent, some of these promises are actually true---but the effort of actually making them happen is often glossed over (e.g. taking stuff off Oracle and making it run "in the cloud" is quite easy to say, but making it happen is quite a challenge).

Re:own cloud

[Karmashock]

the only way you get hacked is if someone hacks YOU. Which is a lot less likely then someone hacking facebook or whatever. If the NSA etc wants to get access they have to penetrate you specifically. The big dragnet operations will largely pass you by if you host it yourself.

What idiocy

[johnlcallaway]

Anyone that posts anything on the Internet (i.e. on another person's computer and network) and demands privacy or security is a moron. You can ask .. but no one is obligated to give it to you. Becoming indignant or angry because they won't is just about the most self-centered and egotistical thing I can think of, thinking someone else owes you something. Why should they?? Because you demanded it?? What do you have to offer in return beyond shutting your mouth??

It's their decision and theirs alone. You want things private and secure, keep them on your own computer. Unplugged from any network.

Anything else is up for grabs.

Re:Worst Response of all Time

[Immerman]

If the data is securely encrypted client-side (using fully audited open source software so you can be sure of that fact), and you don't share the keys with your provider, then it doesn't matter if the server has back doors you can fly a jetliner through. Without your keys all that's stored on the server is white noise.

Use TrueCrypt!

[Anonymous Coward]

As long as you still trust TrueCrypt, there's no reason you shouldn't use an encrypted container file (or multiple smaller containers) in your Dropbox. Some people might not know this, but Dropbox only re-uploads the parts of the file that change (it does a binary comparison), and TrueCrypt typically only updates relatively small sections of the container file when you add/remove/modify a file in the container, so it doesn't take much bandwidth except for the initial upload. Just make sure you dismount frequently enough to allow Dropbox to sync when you make changes. (I'd recommend setting TrueCrypt to automatically dismount after an hour or so of no data being read/written.)

You could use the dynamic disk option when creating the TC container to save bandwidth during the initial upload, if you're starting with an empty container (the size of the container will change, up to a set maximum, to match the contents), but that will have other performance penalties when using the container, and it brings with it the increased risks. In particular, it makes it possible for an analyst to get some idea of how you are storing files in the container, potentially making it easier to break the encryption.

And since it's being stored in the cloud, you should maximize your security by using local keyfiles/tokens rather than a single password. You might as well assume that the whole world has a copy of the container.

For convenience, you can store a portable unencrypted copy of TrueCrypt in Dropbox as well, but you should really only do that if you keep a local copy of the checksums for the binaries and compare them to the files whenever you run them. (That will ensure that nobody has accessed your account and replaced your portable TC binaries with compromised versions capable of stealing your keys.) Or carry a portable version on a USB drive.

The only downside I can see to this is that if you need access to your files on a new machine, you will need to download the whole container, and if the new machine is compromised, you could have your keys stolen. Even so, it's much more secure than using Dropbox on its own, and in my opinion, it's worth the potential inconvenience to have good encryption and cloud access.

Re:Use TrueCrypt!

[GlobalEcho]

Mods: please mod this AC's post up!

HowTo

[bradley13]

How to do this transparently: Use Dropbox normally. Create a folder call ".encrypted". Use "encfs" to mount this folder to some mount point, say "DropboxData". The stuff you put into DropboxData will be will be encrypted locally before being put into the ".encrypted" folder on Dropbox.

Anything you don't consider private goes into Dropbox normally. Anything sensitive goes into DropboxData. You decide the balance.

You can get encfs clients for Linux, Mac, Windows and even Android.

Re: applaud him for being honest

[DocSavage64109]

What's funny is that I gave the same answer to my boss as to how they can prevent me as a sysadmin from reading their confidential documents. Unless they encrypt their files with passwords or keys I don't know, I can come up with a way to access their files. Any other answer would just be a lie.

know them by their acts

[Thud457]

Fair and balanced, mon frere...
Journalistic integrity requires we present both sides of the story: the facts, and my distortions, half-truths, propaganda and outright lies.
It's only fair.

As designed

[nospam007]

"It's hard to do things like rich document rendering if they're client-side encrypted."

The documents are only rendered at the client where the encryption is,nobody else has to render.

Indexing every word in a document at a 3rd party, is kinda counter-productive for encrypted documents.

Re:Worst Response of all Time

[TangoMargarine]

If by "worst response of all time" you're referring to your comment, yes :)

Everyone is Responsible for their Own Security

[sudon't]

People ought to know by now that the internet is not "private." You can't expect privacy from providers. Everyone is responsible for their own security. You can't store something on someone else's server and expect no one will ever look at it, unless you've encrypted it, and encrypted it on your own machine. The only area where we don't have this control is with email, since it takes two to encrypt. But that's not your email provider's fault.

Confirmation

[Kazoo the Clown]

So in other words, Dropbox confirmed Snowden's claims.

No surprise

[LessThanObvious]

I'm neither surprised, nor disappointed by the response from Dropbox. It's frightening how much blind trust I'm seeing businesses place in these cloud storage platforms. I worked for a client that had us posting customer configuration files with clear text passwords on these services. I can only imagine the level of risk others are taking on. This is all uncharted territory and with services being so cheap and easy, it's guaranteed that users, even business users who should know better will take huge risks they don't bother to evaluate. You can outsource the activity of file storage, but when you delegate responsibility you are still accountable for any related failure, ethically if not legally.

Re:what's new

[Opportunist]

But the manager was dead, right? Please say so, I need closure!

Re:what's new

[Opportunist]

Trying to tempt me into buying some of the stuff you're taking?

Re:what's new

[Opportunist]

From the point of a non-native speaker there's really little difference. But thanks for pointing it out.

Then again, I have no idea whether a LART persuades or convinces, but I do like the outcome!