<i>At no time was customer data "leaked" between accounts. This would require that a user not scrub their volume after destroying their server; in this instance data would be recoverable and should be considered not sensitive.</i><p>Is it just me, or is this contradictory? "Data wasn't leaked.. but if it was it was because you didn't check scrub, so it must not have been important." These are two completely different things. Even if the data was not sensitive, it could still be leaked between accounts (which is what happened here).<p>Kudos for committing to fixing the problem though.
* 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 [...] The scrub feature will remain, allowing customers to take an extra level of precaution if they choose to scrub the data after the delete.<p>What is a "clean system", if not a scrubbed one? And if they're scrubbing during create, why leave the scrub option in during destroy? I have to assume that when they say "clean system" they <i>don't</i> mean a scrubbed one, and that worries me.<p>If, as they said, their reason for not scrubbing is because of customers creating and destroying a lot of volumes during the onboarding process, then it seems to me the best solution is one that I believe was suggested in the previous thread. Namely, scrub a volume always whenever it's being used by a new customer. But if the volume is being reused by the same customer, don't bother scrubbing (unless requested), as presumably there are no concerns about leaking information from a user back to the same user.
I've seen the TRIM recommendation pop up a few times, and never with a reply from DO - is this probably how they're going to handle this, or is there a possible reason for not using TRIM?