This is very misleading. From the long exchange in the Gist, to me this appears to be blown out of proportion. While I understand this guy’s point that it’s a “security” issue, it seems to be a feature that was implemented (as noted by DigitalOcean) to combat human error - oops I deleted that droplet, I need it back.
I’ve created a few test droplets and removed them, I never really paid any attention to the fact that I can still recover them up until a certain time. This just sounds like someone unhappy with the feature. If that level of security and assurance is needed, I don’t think a VPS provider is where you should be looking to store your data in the first place.
Having worked for a large German web hosting company (providing virtual servers, shared hosting including email, MySQL databases, the usual stuff), I can tell you that whenever you have a large amount of users, you will always have quite a few users that accidentally delete some of their stuff, and want it back. And, of course, the users paying the least for the service scream the loudest (which shows in negative comments on web forums and social media and definitely has an effect on the company’s reputation), so you always implement some mechanism to make it possible to recover data that was “deleted”. And you usually do so by locking or disabling said data (making it inaccessible to the user), marking when it was disabled, and then delete after a certain period, e.g. after a month. Usually, most users will complain within a day or two to get their stuff recovered. Of course that’s not exactly cool for people who expect their data to be securely deleted immediately, but it greatly increases user satisfaction whenever users make mistakes and click the wrong buttons.
I don’t see a problem. The data is destroyed. It’s removed from the VM host within a few minutes, and entirely within 48 hours. It’s a UI issue since the scrub data feature gives a misleading (and strange*) “Estimated Destroy Time” of a few minutes. That only applies, as far as I can tell, to wiping the instance from the VM host.
As for tweaking the SSH host key, that likely has to do with their build process. On any VPS you should re-generate the host key. Even if it wasn’t obviously “changed” there’s no guarantee the hosting provider didn’t keep a copy of it.
I also find that Digital Ocean has allocated a pool of IP addresses for me that gets re-used. The author was surprised to have been re-allocated the same address; for me that happens all the time.
* It’s strange because (a) why, as a user, would I care how long it takes their internal systems to wipe the data, and (b) it should be instant — delete the encryption key. This implies they aren’t encrypting your VM data at rest.
This is very misleading. From the long exchange in the Gist, to me this appears to be blown out of proportion. While I understand this guy’s point that it’s a “security” issue, it seems to be a feature that was implemented (as noted by DigitalOcean) to combat human error - oops I deleted that droplet, I need it back.
I’ve created a few test droplets and removed them, I never really paid any attention to the fact that I can still recover them up until a certain time. This just sounds like someone unhappy with the feature. If that level of security and assurance is needed, I don’t think a VPS provider is where you should be looking to store your data in the first place.
Having worked for a large German web hosting company (providing virtual servers, shared hosting including email, MySQL databases, the usual stuff), I can tell you that whenever you have a large amount of users, you will always have quite a few users that accidentally delete some of their stuff, and want it back. And, of course, the users paying the least for the service scream the loudest (which shows in negative comments on web forums and social media and definitely has an effect on the company’s reputation), so you always implement some mechanism to make it possible to recover data that was “deleted”. And you usually do so by locking or disabling said data (making it inaccessible to the user), marking when it was disabled, and then delete after a certain period, e.g. after a month. Usually, most users will complain within a day or two to get their stuff recovered. Of course that’s not exactly cool for people who expect their data to be securely deleted immediately, but it greatly increases user satisfaction whenever users make mistakes and click the wrong buttons.
I don’t see a problem. The data is destroyed. It’s removed from the VM host within a few minutes, and entirely within 48 hours. It’s a UI issue since the scrub data feature gives a misleading (and strange*) “Estimated Destroy Time” of a few minutes. That only applies, as far as I can tell, to wiping the instance from the VM host.
As for tweaking the SSH host key, that likely has to do with their build process. On any VPS you should re-generate the host key. Even if it wasn’t obviously “changed” there’s no guarantee the hosting provider didn’t keep a copy of it.
I also find that Digital Ocean has allocated a pool of IP addresses for me that gets re-used. The author was surprised to have been re-allocated the same address; for me that happens all the time.
* It’s strange because (a) why, as a user, would I care how long it takes their internal systems to wipe the data, and (b) it should be instant — delete the encryption key. This implies they aren’t encrypting your VM data at rest.