For fuck's sake, now you're just lying.
Not scrubbing has been the default - a user doesn't have to "explicitly not scrub". A simple unadorned "destroy" api command creates the circumstance in which the data is not destroyed, but made available to others.
If no customer data leaked between accounts, how was I able to read someone else's stack traces[1], web logs[2], and customer tokens[3] on a freshly provisioned VM?
What follows is evidence to directly support the claim that you're lying through your teeth to save face after having been caught being grossly irresponsible with your customers' data.
Please start acting like professionals.
[1] http://i.imgur.com/TMp2kdf.png
You are aware you are talking to more than one person at DigitalOcean, right? Their post has contradictions in it because the person that wrote it isn't the same person who is implementing the fix. Clearly they know they fucked up, are fixing the fuck up, and are trying to implement damage control. The people doing the fix for the fuckup are fixing things because they agree with you. The people writing the copy for the damage control don't agree with you. It's a clear case of cognitive dissonance, which isn't surprising given there is more than one person involved over there.
Individuals already have cognitive dissonance to begin with, it just gets worse when more people are involved. A company without cognitive dissonance would have never implemented this to begin with. Celebrate the fact you got them to change it and move on. Fighting them with blaming statements is just going to make the people who actually fixed it for you sad and disappointed. That's not what any of us want.
And, you are right, someone over there is just lying and someone else over there in charge should take them aside and explain how it's not cool.
* There are contradictions in claim
* There are misstatements of fact
* They are offering a poorly qualified apology
> Fighting them with blaming statements is just going to make the people who actually fixed it for you sad and disappointed.
Disagree 100%. If the management team can't get their head around the "right" decisions from an engineering perspective, the engineers are in for a world of sadness and disappointment. The management at DO need to hear every one of the criticisms being leveled here and on their own communications channels.
Corporations always speak with one voice. If that voice says something wrong or inconsistent, it is not the public's problem, it is the corporation's. No excuses. Ever.
"As a result, we switched the default mode away from scrubbing to improve performance, given that customers would have complete control over this action themselves."
Also, I think they presume a leak to be qualified by the data being sensitive which would not be leaked had it been scrubbed, for which they provide an option. This has to be assumed, otherwise one would never need to scrub.
Still, certainly looks to be a pretty big mistake in communications.
In the control panel, its quite clear, and easy to simply check scrub on. I agree that this change on the API front should have been articulated. However, Moisey acknowledge their mistake, let's move past it.
There are many ways to securely scrub an SSD without subjecting it to a full write. They were outlined in the original thread.
They've leaked customer data between VMs. Their claims that this isn't true are false. Look at the screenshots!
This is a profound, never-ever-should-happen gap in data security, and it is yet another instance where DigitalOcean comes out looking remarkably amateurish.
Conversationally, I would have expected their hypervisor to have been doing thin provisioning: That until you write data to a block the block is 0s (having no provisioning on actual storage). And if you write 0s, that too isn't actually provisioned on real storage. And when you write actual data, well that is what the block now contains.
A new VM should have a new disk file.
When I create a vm I create a vmdk file that represents the disk. When I delete the vm I also delete the vmdk file. If I then create a new vm I would use a new vmdk file.
Apparently that is not the way digital ocean does things, but how do they do stuff then?
