5 ms·

Both retaining the IP and being able to recover a destroyed droplet are strictly features. It would be a problem if someone else could create a droplet and reco

Both retaining the IP and being able to recover a destroyed droplet are strictly features. It would be a problem if someone else could create a droplet and recover your data, not when you can do it.

hngiszmo 13y ago
While I love these features of my droplets, I see how it barely is a far stretch to construct situations in which you wouldn't want to be able to reconstruct it. Most likely destroying evidence is the most obvious one.
- devhen 13y ago
  In which case you should be manually scrubbing your data on your own. Problem solved.
userbinator 13y ago
> It would be a problem if someone else could create a droplet and recover your data, not when you can do it. This. Sometimes it really is better if it's not truly gone forever - in other words, you still have the option of recovery. I'm speaking from the experience of someone who has accidentally lost important, irreplaceable data that had yet to be backed up. Especially after reading this: There was also an incident where a third party provisioning service which integrates with our cloud as well as others was compromised and all of the servers for those customers were destroyed
- devhen 13y ago
  Exactly. The default behavior is exactly as it should be-- scrub the VM itself but keep a snapshot for 48 hours in case it was deleted accidentally. There is no security concern here but if some users are still upset with this default behavior then they should be manually scrubbing their sensitive data prior to deleting the droplet or, better yet, they should be using their own hardware. Frankly, I'm shocked at a lot of the responses here. When I first came across this article it was immediately obvious to me that this was not an actual security concern but rather a mixture of misunderstanding and skepticism. So I came here to hackernews feeling entirely confident that this article would have been efficiently debunked and instead I find all manner of ill-informed arguments. The people that don't understand the original article, its fallacies, and the reality of how Digital Ocean is handling droplet destroys, should not be running servers IMO. This stuff should be obvious to you and furthermore, if your data is particularly sensitive, you should have already been under the assumption that the host could not be trusted and that data scrubbing must be done manually.

Both retaining the IP and being able to recover a destroyed droplet are strictly features. It would be a problem if someone else could create a droplet and recover your data, not when you can do it.

hngiszmo 13y ago

While I love these features of my droplets, I see how it barely is a far stretch to construct situations in which you wouldn't want to be able to reconstruct it. Most likely destroying evidence is the most obvious one.

devhen 13y ago
In which case you should be manually scrubbing your data on your own. Problem solved.

userbinator 13y ago

> It would be a problem if someone else could create a droplet and recover your data, not when you can do it. This. Sometimes it really is better if it's not truly gone forever - in other words, you still have the option of recovery. I'm speaking from the experience of someone who has accidentally lost important, irreplaceable data that had yet to be backed up. Especially after reading this: There was also an incident where a third party provisioning service which integrates with our cloud as well as others was compromised and all of the servers for those customers were destroyed

devhen 13y ago
Exactly. The default behavior is exactly as it should be-- scrub the VM itself but keep a snapshot for 48 hours in case it was deleted accidentally. There is no security concern here but if some users are still upset with this default behavior then they should be manually scrubbing their sensitive data prior to deleting the droplet or, better yet, they should be using their own hardware. Frankly, I'm shocked at a lot of the responses here. When I first came across this article it was immediately obvious to me that this was not an actual security concern but rather a mixture of misunderstanding and skepticism. So I came here to hackernews feeling entirely confident that this article would have been efficiently debunked and instead I find all manner of ill-informed arguments. The people that don't understand the original article, its fallacies, and the reality of how Digital Ocean is handling droplet destroys, should not be running servers IMO. This stuff should be obvious to you and furthermore, if your data is particularly sensitive, you should have already been under the assumption that the host could not be trusted and that data scrubbing must be done manually.