>>Our first and immediate update is to ensure that a clean system is provided during creates, regardless of what method was taken for initiating a destroy. Engineers are updating the code base right now to ensure that will be the default behavior, and we will provide another notice when that code is live.
The scrub feature will remain, allowing customers to take an extra level of precaution if they choose to scrub the data after the delete.
I don't think everyone will be happy until you make scrubbing the default. Or I guess those direct reads with the "dd" command stop yielding data from previous VM instances, which it does kinda sound like DO is preparing to do. If scrubbing isn't going to be default, I'm kinda curious what DO will be doing to ensure clean VMs.
Well that just made my brain explode. This is going to make it that much harder to argue that public clouds take security seriously. I'd love to see an example of what data they think is fine to leak, since that seems to be their performance strategy.
Indeed. The non-scrub option simply should not exist. Are there use cases for non-scrub? Yes. Are the risks worth it? No, at least in my opinion.
Forget to check that box? Oh well, better hope the next droplet doesn't go and read your data.
Moderately competent developer doesn't realize the implications of not checking that box? Oh well, better hope that developer didn't have too much sensitive data on the droplet.
Etc etc. Security is the big area where the default should be to err on the side of caution - often removing choices that are simply too dangerous (when, for example, the tradeoff is a tiny amount of performance gain).
I say this all as someone who likes and is a customer of DO. I am disappointed.
So is it that they just didn't want to take the time to do it, or they were afraid of shortening the life-span of their SSDs by cleaning them after use?
Typical combination of: ease of implementation, desire to minimize overhead of security, and the perceived difficulty and low utility of the attack vector.
There are fundamental tradeoffs that happen when you take the VPS / cloud hosting route, and security is definitely one of them. There are reasons why Amazon, for example, doesn't just casually mix in their own services into AWS instances. Security is still a hard problem.
