Hacker News new | past | comments | ask | show | jobs | submit login

Oh, hey guys, they've responded. It's no big deal, they just disabled the security because because _users were complaining_.

Turns out it "add[s] a very large time to delete events" when you actually delete things when a user makes an api call to DESTROY. Who knew?

http://i.imgur.com/MFW8ng6.png




I got the same response from them via Twitter. I don't think it's acceptable.

I worked for a hosting company that made data destruction their problem (i.e. we wiped the disks after the instance was terminated) because we didn't want new customers seeing non-zeroed disks and thinking we do not care about security.


Damn straight.

If I have something important on a VM it is purged before issuing a destroy. I will overwrite the block device myself so I know it is empty.

Why should I have to pay for DO to do the same again just because someone can't be bothered to read the manual.


As I replied to you elsewhere, I feel your comment here may lead people to believe that it would cost DigitalOcean money to correct this behavior.

This is wrong, it is costing DigitalOcean money not to fix it - in terms of SSD lifetime, not TRIMing those blocks increases fragmentation of the internal physical layout of the pages of flash memory. The behavior of DigitalOcean's virtual machines has surprisingly managed to achieved the worst possible outcome. Their hardware is being misused and their customer's data is being mishandled.


Well that's stupid. They should also take care of the case where I delete a vm. What do I care that it takes a long time for them to delete the data? That shouldn't cost me any money, as I have freed the resources from my account.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: