The DigitalOcean is boiling… wocka wocka
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?
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.
@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.
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.