On the other hand, keeping copies of the user's data after you say you've deleted it doesn't sound too ethical to me. I don't expect immediate purging, but I also don't expect potentially sensitive files to linger for months after they were supposed to be deleted.

I think a better system would be to warn about big deletion events (e.g. send an email) to allow the user to revert it within the 30-day period.

This is a fair concern, but I think the issue of recovering files is much more important than the issue of retention of deleted files to the huge majority of the Dropbox user base. I imagine most privacy-conscious users would use an online sync service that offers encryption by default, etc.

Then you have the opposite problem; privacy-centered users complaining "Dropbox keeps your data even when they say it's permanently deleted! Here's proof!!"

Like any other security measure, it's a question of tradeoffs.

That is their problem rather than anyone else's of course, but that isn't what they'll shout if it bites them in the arse later - they'll concentrate on shouting about the involvement of Service X rather than pontificating on whether involving Service X for that particular data was a good idea on their part in the first place.

If they are encrypting their data client-side before the sync service touches it, then they may have thought they were safe until a key leaked and they recoded everything with new keys only to find that arched copies somewhere out there were still openable with the previous (now leaked) key(s).

Edit to add: Dropbox's sole purpose is to sync files between different physical machines. Which, now that I think about it, seems sort of anachronistic.

In cloud storage, the authoritative version of the file lives in the cloud and each device just accesses it. But in Dropbox, the authoritative version is on every machine. By default, every copy is authoritative, and actions are synced.

This sort of "many originals" architecture seems to confuse people. The article author here is clearly thinking of Dropbox like cloud storage--he checked the web interface, saw his files, and thought it was all good.

But in Dropbox the web interface is not authoritative, the local copy is.

Use proper backup services, instead, like Memopal.

"Dropbox is a home for all your photos, docs, videos, and files". -- https://www.dropbox.com/tour/1

Its actually more than a little annoying.

It is unwise to use anything as the sole storage of important files. Personally, I think cloud backup is safer then one backing up files to a DVD or tape backup but I just won't keep personal files on any cloud service.

Never just have one point of failure!

I don't think that they are. More like the modern incarnation of a file server. Like a fileserver, they have resiliency against service failure or individual storage system failure (via S3). Cool stuff, but it ain't backup.

YES: from DropBox's point of view - this is a serious bug even ignoring what other actions the users have/not taken to protect their data.

And NO: this sort of thing is one of the key reasons not to use such a service as a sole backup - linking the two when trying to educate users on the importance of thinking about data safety, so we can't separate the two as one is important when hammering the other point home...

> Even for files that are deleted intentionally and unambiguously by the user, I'm astonished that Dropbox actually deletes the files at the end of the 30-day restore window. I would expect them to keep the files for some multiple of the publicly-stated restore deadline

That would cause significant consternation in some areas. If I explicitly delete a file I might explicitly want it gone within the stated window and no later and would therefore be unhappy if I found the data still available (even if I had properly encrypted it before it touched the cloud service so noone else could read it).

> For files that aren't intentionally deleted by the user but are "de-synced",

I definitely agree there - it sounds like that process needs some transactional workflow wrapped around it so that:

1. Client and server don't do anything until they've both agreed what to do (then they can both go away and do it even if the connection drops, safe in the knowledge that the action is correct).

2. The client and server record what has been agreed as part of that transaction protected process, so in the case of an unclean stop during the process it can be resumed/retried.

3. Some process may need to be in place for one side rolling back if the other detects a failure applying the agreed actions.

Of course this is a fair bit of work for something that won't happen often, particularly when you consider that there might be more than one active connection to a set of files at any given time so it might not be a simple two-way merge operation, so DB may have other priorities - but the bad PR from it happening and not being cleanly dealt with is something that they need to consider if making that sort of decision.

> "The user should have kept multiple redundant copies" is not an excuse for a poorly managed online backup service

Agreed. But "the single backup service failed" is similarly not something that is going to encourage me to have sympathy for the user!

Sync services are excellent secondary backups, and they satisfy the "off site" requirement that a great many home and small-office users neglect (I know people who worked for a small company which died because the backups were in the same building as the active data so one fire took out the lot), but no one should trust them as their only backup. I even recommend against multiple sync services as your only backups as that in itself can cause problems (when bugs or other peculiarities from one interact badly with similar behaviours in another).

Using just a sync service means you have no off-line (or even semi-offline) backup, which is as bad as not having any off-site copies.

Of course getting this involves educating users as to the risks they are taking, which is a point notoriously difficult to get across, so while I don't expect a service like DB to be perfectly bug free (and therefore wouldn't trust it as an only backup) I think such services need to help the education process by being a little less indigenous about the safety issue and making sure their users know that an accidental delete will be propagated everywhere and be unrecoverable after a time. This will never happen though: "please use some other backup option too in case ours goes wrong" is not a sentiment marketing departments or investors will want to see publicly stated!

Very few (if any) users who explicitly delete a file want that file recoverable within 30 days but not after that. They either want the file recoverable for a much longer period of time or they want the deleted file to be irrecoverable immediately. For the latter option, Dropbox offers the ability to "permanently delete" files. It requires at least four clicks to accomplish, displays a warning, and is driven entirely via the website rather than through the Dropbox client.

If you think about it, that sums up almost any robust back-up system you go to the effort of setting up, properly testing, and maintaining over time. For that matter, it applies to almost any insurance policy in any context.

I expect most of us would still agree that potential catastrophic damage if you're the unlucky one can justify spending the time/money/resources to set up proper back-ups and insurance, though, and surely this is the case if you're running a service where robust file handling is your major value proposition.

Exactly, which is why people should think harder than they do about backups. You should make sure that you are not exposed to risk you don't want to be exposed to because someone else's development priorities differ from your point of view.

True data protection is unfortunately a complicated business and most people see the flashy presentations on services' sites and trust all is well without giving it a second thought.

While I agree it should be the service's responsibility to cover these eventualities, it is not good practise to assume that they do. You might misunderstand what they do and not see risk were it is present, they might have honest coding mistakes that cause problems down the line, there could be ineptitude anywhere down the line, and so forth. If you are paying for their service then you might legitimately expect to be covered by some for of insurance for loss in the event of it being caused by a problem in the code/infrastructure, but never assume that until being explicitly told it is present and you have read the small print, and don't ever assume this at all for a free/cheap service.

Maybe the whole issue is: a local delete turns into a remote delete, and that's pretty much non-reversible (unless you realize what you did, later)

Maybe they should add something like "You just deleted a lot of files from your DropBox, are you sure, please review and confirm" (if this was done through sync)