5 ms·

Wait a second. Why does this option exist at all? Are you saying there are people who DO NOT WANT their data destroyed when they destroy a VM? Who are these peo

Wait a second. Why does this option exist at all? Are you saying there are people who DO NOT WANT their data destroyed when they destroy a VM? Who are these people?

deleted 13y ago
[deleted]
jd007 13y ago
It's probably there for DO's sake. SSDs have limited rewrite cycles, and each secure wipe will definitely shorten the lifespan of the drive much more than a simple quick wipe. This translates into cost savings.
- thirsteh 13y ago
  Worst cost-saving measure ever.
- switch007 13y ago
  Yes. This is a shitty default peddled as a benefit for the customer, when in fact it benefits DO.
  - sneak 13y ago
    No other provider charges you extra to erase your data when tearing down an instance. It's called a dark pattern.
    - dmxt 13y ago
      Most other provider use hard drives and they're different from SSD.
    - bluefinity 13y ago
      Okay, the misinformation is getting a little out of hand here. DigitalOcean certainly aren't charging you to erase your data, all you have to do is check the "Scrub Data" checkbox. Yes, you have to pay for the time your VPS is on while erasing, but that's perfectly reasonable.
      - revelation 13y ago
        Why would that be perfectly reasonable? They have an obligation to not make my data available to other people, I don't give a rats ass about the technical details of doing that.
  - larrys 13y ago
    "when in fact it benefits DO" I could argue that it benefits the customer as well. If it costs DO more (because of disk wearout) then in theory they would have to raise prices in order pay for their higher costs. And those higher costs could then disrupt the balance in pricing that makes them attractive. My point is that forgetting the numbers you can't say it only benefits them. Being able to offer lower prices (because your expenses are lower) also benefits the customer as well.
- jonknee 13y ago
  If they can't afford to use SSDs properly they should not use SSDs.
userbinator 13y ago
It's much faster and there are certainly people who don't care because the data is worthless to anyone but them.
- kbar13 13y ago
  in other words, the only people who are affected are those who don't know the importance of scrubbing their data?
  - jrs235 13y ago
    Come on people! DO is a developers playground ($5/month!!!!) not a place to host sensitive production data.
    - smsm42 13y ago
      Sensitive is a relative term. You do development, you install a private key on the VM, you grant that key access to your system in order to test new integration prototype, you delete the VM before you disable the key - and voila, you got private key with access to your systems in a hands of a random stranger. Of course, the solution would be to disable the key access first - but how many devs are trained in security procedures to this level? How many can follow them flawlessly over repeated tedious cycles of development and resist the temptation of make shortcuts? Proper procedures should make it easy for people to do security, otherwise they are part of the problem.
      - jrs235 13y ago
        "Proper procedures should make it easy for people to do security, otherwise they are part of the problem." Correct. And leaving the proper procedure in other people's hands is the problem. The best procedure [in testing a new intergration prototype] would be to create a new special test key and properly track and maintain that it is only enabled during the known testing time frame and then properly "disposing"/"revoking" it in the system YOU control. We can argue all day that DO should scrub the data by default and prevent new instances from low level access... however security relies on trust. So, do you TRUST (and KNOW) that checking the "scrub data" check box actually works and does what it says it does? If it doesn't, its beyond your control. And if you care about proper procedures and security you either a) don't use systems/servers beyond your control (if you are that concerned...) and/or b) rely on proper procedures and things you can and do control. I don't know what happens in DOs infrastructure... maybe there is some other leak I'm unaware of so to limit any damage for testing I will properly create and control short lived test keys.
iagooar 13y ago
I use DO for bootstrapping and trying out new ideas, programs & co. There is no information I can think about I would wish to get wiped off of the SSD.
- sneak 13y ago
  Source code? SSL private keys? Private keys used for deploying code or configs from Github? New Relic license codes? AWS access keys? Pcap dumps? Database passwords? Deleted blog posts? irssi cybersex paged out to a swapfile? Seriously, if there's nothing on your cheap sandbox server that you don't want published, you're probably not using it in the first place.
  - Selfcommit 13y ago
    Reading your comments in the link, and comments in this thread, I find you to be alarmist at best. Yes, this issue needs to be raised. No, you can't say that anyone who doesn't agree is a non-factor. You have the option to scrub your data anytime you like, I've always understood that wasn't the default on DO.
- icelancer 13y ago
  Then certainly you don't mind giving me your root login?
  - jacobr 13y ago
    To a server you have discarded?
dspillett 13y ago
If you care about your data then the erase will not protect you enough anyway, if you think it does then you've probably misunderstood the underlying architecture a little. The data for your virtual machine's virtual disk(s) will not always be in the same place, it may get moved around the storage volume or moved between storage volumes and this will be completely transparent to you. It may also get stored on backup volumes too. When you "secure wipe" the disk as you kill the VM all you are doing it wiping the data that is in the current location not any latent copies that may be sat elsewhere (as backups or "ghost" data sat in currently unallocated bits of physical media). The only way to grantee your data is stored securely and is gone securely when you want it gone, is to use full-volume encryption from the start and make sure that the key's are never stored at the provider side (this does mean that you need a mechanism by which you can provide the key(s) to the VM whenever it reboots for some reason). That way there is no need to wipe the current store or worry about ghost data elsewhere: just destroy all copies of the keys for those volumes. Of course there is still some risk as the keys need to be in RAM somewhere so the encrypted volumes can be accessed at all, but once you get to that level of concern you can only be sure you are secure by having your own physical kit. Of course not all current hardware sharing solutions can support full volume encryption as you don't really have a proper volume(s) that you can encrypt and put filesystems in, just a part of a larger filesystem pretending to be one (and you can't mount things so you can't use a file-based volume instead)... tl;dr: wiping the VM's disks does NOT protect you from this sort of thing, using properly implemented full volume encryption will (as much as is possible in a shared virtualisation host, iff your hosts's solution can support FVE in the guest VMs/containers at all).
- jcrawfordor 13y ago
  You make it sound like there's no valid point of security in between "anti-the-next-random-guy" and "anti-sophisticated-governments." There are a lot of people who care about their data enough that it shouldn't be left lying around for passersby, but not so much that they're going to implement FDE. I'd call them "normal people."
  - dspillett 13y ago
    The suggestion of using TRIM does not (in all cases) protect against accidental data visibility to the "next random guy", it doesn't even protect from some other current random guy as your container could have moved and left another user with access as their new container got created over the space you used to occupy - so unless you have another method that hasn't been discussed yet there isn't a point in between: you protect yourself from both or you protect yourself from neither. If you need to be sure your instructions to wipe data do protect you from that random other guy then you either need to use good encryption (it doesn't have to be full volume encryption but once you get to the point of caring it is probably easier to go the whole hog than do it piecemeal) or you need to have dedicated physical storage (something a VPS provider generally doesn't offer. Of course the provider could instigate full data wiping for all relevant operations, but that imposes I/O load that will affect all other users of the given host machine(s) unnecessarily (I say "unnecessarily" because most won't care as their bulk data is not sensitive and they've invalidated associated things like SSH keys anyway, the host will take the attitude that if your data is sensitive you need to take measures to protect it).

Wait a second. Why does this option exist at all? Are you saying there are people who DO NOT WANT their data destroyed when they destroy a VM? Who are these people?

deleted 13y ago

[deleted]

jd007 13y ago

It's probably there for DO's sake. SSDs have limited rewrite cycles, and each secure wipe will definitely shorten the lifespan of the drive much more than a simple quick wipe. This translates into cost savings.

thirsteh 13y ago
Worst cost-saving measure ever.
switch007 13y ago
Yes. This is a shitty default peddled as a benefit for the customer, when in fact it benefits DO.
- sneak 13y ago
  No other provider charges you extra to erase your data when tearing down an instance. It's called a dark pattern.
  - dmxt 13y ago
    Most other provider use hard drives and they're different from SSD.
  - bluefinity 13y ago
    Okay, the misinformation is getting a little out of hand here. DigitalOcean certainly aren't charging you to erase your data, all you have to do is check the "Scrub Data" checkbox. Yes, you have to pay for the time your VPS is on while erasing, but that's perfectly reasonable.
    - revelation 13y ago
      Why would that be perfectly reasonable? They have an obligation to not make my data available to other people, I don't give a rats ass about the technical details of doing that.
- larrys 13y ago
  "when in fact it benefits DO" I could argue that it benefits the customer as well. If it costs DO more (because of disk wearout) then in theory they would have to raise prices in order pay for their higher costs. And those higher costs could then disrupt the balance in pricing that makes them attractive. My point is that forgetting the numbers you can't say it only benefits them. Being able to offer lower prices (because your expenses are lower) also benefits the customer as well.
jonknee 13y ago
If they can't afford to use SSDs properly they should not use SSDs.

userbinator 13y ago

It's much faster and there are certainly people who don't care because the data is worthless to anyone but them.

kbar13 13y ago
in other words, the only people who are affected are those who don't know the importance of scrubbing their data?
- jrs235 13y ago
  Come on people! DO is a developers playground ($5/month!!!!) not a place to host sensitive production data.
  - smsm42 13y ago
    Sensitive is a relative term. You do development, you install a private key on the VM, you grant that key access to your system in order to test new integration prototype, you delete the VM before you disable the key - and voila, you got private key with access to your systems in a hands of a random stranger. Of course, the solution would be to disable the key access first - but how many devs are trained in security procedures to this level? How many can follow them flawlessly over repeated tedious cycles of development and resist the temptation of make shortcuts? Proper procedures should make it easy for people to do security, otherwise they are part of the problem.
    - jrs235 13y ago
      "Proper procedures should make it easy for people to do security, otherwise they are part of the problem." Correct. And leaving the proper procedure in other people's hands is the problem. The best procedure [in testing a new intergration prototype] would be to create a new special test key and properly track and maintain that it is only enabled during the known testing time frame and then properly "disposing"/"revoking" it in the system YOU control. We can argue all day that DO should scrub the data by default and prevent new instances from low level access... however security relies on trust. So, do you TRUST (and KNOW) that checking the "scrub data" check box actually works and does what it says it does? If it doesn't, its beyond your control. And if you care about proper procedures and security you either a) don't use systems/servers beyond your control (if you are that concerned...) and/or b) rely on proper procedures and things you can and do control. I don't know what happens in DOs infrastructure... maybe there is some other leak I'm unaware of so to limit any damage for testing I will properly create and control short lived test keys.

iagooar 13y ago

I use DO for bootstrapping and trying out new ideas, programs & co. There is no information I can think about I would wish to get wiped off of the SSD.

sneak 13y ago
Source code? SSL private keys? Private keys used for deploying code or configs from Github? New Relic license codes? AWS access keys? Pcap dumps? Database passwords? Deleted blog posts? irssi cybersex paged out to a swapfile? Seriously, if there's nothing on your cheap sandbox server that you don't want published, you're probably not using it in the first place.
- Selfcommit 13y ago
  Reading your comments in the link, and comments in this thread, I find you to be alarmist at best. Yes, this issue needs to be raised. No, you can't say that anyone who doesn't agree is a non-factor. You have the option to scrub your data anytime you like, I've always understood that wasn't the default on DO.
icelancer 13y ago
Then certainly you don't mind giving me your root login?
- jacobr 13y ago
  To a server you have discarded?

dspillett 13y ago

If you care about your data then the erase will not protect you enough anyway, if you think it does then you've probably misunderstood the underlying architecture a little. The data for your virtual machine's virtual disk(s) will not always be in the same place, it may get moved around the storage volume or moved between storage volumes and this will be completely transparent to you. It may also get stored on backup volumes too. When you "secure wipe" the disk as you kill the VM all you are doing it wiping the data that is in the current location not any latent copies that may be sat elsewhere (as backups or "ghost" data sat in currently unallocated bits of physical media). The only way to grantee your data is stored securely and is gone securely when you want it gone, is to use full-volume encryption from the start and make sure that the key's are never stored at the provider side (this does mean that you need a mechanism by which you can provide the key(s) to the VM whenever it reboots for some reason). That way there is no need to wipe the current store or worry about ghost data elsewhere: just destroy all copies of the keys for those volumes. Of course there is still some risk as the keys need to be in RAM somewhere so the encrypted volumes can be accessed at all, but once you get to that level of concern you can only be sure you are secure by having your own physical kit. Of course not all current hardware sharing solutions can support full volume encryption as you don't really have a proper volume(s) that you can encrypt and put filesystems in, just a part of a larger filesystem pretending to be one (and you can't mount things so you can't use a file-based volume instead)... tl;dr: wiping the VM's disks does NOT protect you from this sort of thing, using properly implemented full volume encryption will (as much as is possible in a shared virtualisation host, iff your hosts's solution can support FVE in the guest VMs/containers at all).

jcrawfordor 13y ago
You make it sound like there's no valid point of security in between "anti-the-next-random-guy" and "anti-sophisticated-governments." There are a lot of people who care about their data enough that it shouldn't be left lying around for passersby, but not so much that they're going to implement FDE. I'd call them "normal people."
- dspillett 13y ago
  The suggestion of using TRIM does not (in all cases) protect against accidental data visibility to the "next random guy", it doesn't even protect from some other current random guy as your container could have moved and left another user with access as their new container got created over the space you used to occupy - so unless you have another method that hasn't been discussed yet there isn't a point in between: you protect yourself from both or you protect yourself from neither. If you need to be sure your instructions to wipe data do protect you from that random other guy then you either need to use good encryption (it doesn't have to be full volume encryption but once you get to the point of caring it is probably easier to go the whole hog than do it piecemeal) or you need to have dedicated physical storage (something a VPS provider generally doesn't offer. Of course the provider could instigate full data wiping for all relevant operations, but that imposes I/O load that will affect all other users of the given host machine(s) unnecessarily (I say "unnecessarily" because most won't care as their bulk data is not sensitive and they've invalidated associated things like SSH keys anyway, the host will take the attitude that if your data is sensitive you need to take measures to protect it).