That's like dumpster diving only on planetary scale and no actual dumpsters involved. Wonders of technology and interface designers that don't realize people don't read docs and expect things to work properly by default.

But the dd thing is really embarrassing here, I mean I'd expect some data on shared hardware being recoverable using hardcore forensics, but there are enough levels between hardware and dd that using at least one of them to make old data inaccessible should be both possible and pretty cheap.

If you make an API call that asks for your data NOT to be scrubbed, then it's not a leak that your data isn't scrubbed--you asked for it. If you haven't read the docs, you might not be aware that you're asking for it. That's a Bad Thing. No question. It should be enabled by default, to prevent unknowing users from leaking their own data. If you ask for a scrub and you can still find data on the scrubbed block device, then you have a leak from DO.

I'd agree with you, except that in this case the API call is called "destroy". Were it called "deallocate", this would be a different story.

I read the API documentation. It's pretty short. Here's the relevant bit:

"scrub_data Optional, Boolean, this will strictly write 0s to your prior partition to ensure that all data is completely erased."

If I didn't already know about this issue, I would never Have thought that leaving this option out would leak all of my data. My reading of the above option would be that, with it off, they would leave your data on the drive until it was reused, leaving open the possibility that e.g. the FBI could seize the equipment in the meantime and access it.

The opposite of "write zeroes to your partition" is not "give all of your data to the next customer".