Home > Uncategorized > The DigitalOcean is boiling… wocka wocka

The DigitalOcean is boiling… wocka wocka

There are some errors here, corrected at the end

A little while ago (8 hours), it became clear that the framework utilized by DigitalOcean doesn’t enforce a secure deletion method when a user deletes a droplet (VMs). This means that previous data is recoverable by new users who are allocated the same space. As Jed Smith states, this data leakage vector is common among hosting providers.

Here is a valuable exchange:

As far as I can tell here, there is no unexpected behavior that isn’t documented or stressed. In both our API documentation, and our control panel, we note that you must either pass a flag or check the box to security delete the data. As far as I can tell, the flag is currently functionally correctly.

Is the complaint that customer data is being leaked from VMs? That the flag being passed via our API/Dash isn’t actually working? Or, that our policy on not doing a secure delete by default isn’t something you agree with?

John Edgar (Chief Tech Evangelist)

To frame full disclosure as irresponsible is unprofessional. There is nothing irresponsible about full immediate disclosure.

It’s also a red herring. You yourself said that this is a design decision, working as intended, and that I should tell people about it to raise understanding and awareness.


This is simply a case of Digital Ocean using dark patterns and user-hostile defaults. No other major cloud provider charges their customers extra to not give their data to the next user.

You don’t take security seriously, as this design and your tweets show.

Jeffrey Paul (owner datavibes.net and eeqj.com)

@sneak I appreciate your product feedback.

I think it’s valuable, and I’ll be sharing it with the rest of our company, including our whole C-team, tomorrow morning at our weekly kick-off meeting. I’ll report back with what the result of that is. Like I’ve said 100000 times, and can’t be any more clear about, we do take security seriously.

If you’d like, I’ll happy give you a call tomorrow.

— John Edgar

Show me any other vps provider that silently provides access to customer A’s data to customer B after receiving commands from customer A to destroy their instance and then I’ll believe you guys aren’t at the very bottom of the “takes security seriously” list.

A single counterexample would convince me you’re not totally insane to think this a reasonable default.

— Jeffrey Paul

So… use `shred`, and stop trusting third parties, with their own interests in mind, to take care of what you should take care of with your own internal policies.

Infuriating Update:
Okay… So maybe I shouldn’t post before I drink coffee (particularly to a github issue), but I did misunderstand the problem. It appears that DigitalOcean changed a default value for a setting in their API, and that’s the extent of the controversy. The github ticket was opened with a single API user, fog.io; which is basically host management magic that allows users to easily manage systems with many IaaS providers.

I’m happy that I don’t look like a jackass, because my point on user/dev accountability still holds true. The fog.io developers didn’t hard code a value in their API call, and this allows a few fog.io devs and users to call DigitalOcean “shitty?” Hell no. It’s your responsibility to code securely, and that means you don’t get to code all “shitty” like and then blame someone else for the screw up, particularly if that screw up is so critical to you.

This point goes beyond the general acceptance of risk when dealing with a third party [hosting provider]; it is up to you to understand and reduce the introduced risk. That responsibility, and all failures therein, should always be left on you and on no one else. You should be accountable always, for everything you do.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: