Hacker News Reader

Comment by jlawer | Hacker News Reader

Talk about a link bait title. Its a bit hard to call it a leak,Its a configuration option that is well presented in the web UI. It is optional as it adds ~ 10 minutes of billing to the small 512mb VMs and as such it is optional if you do it.

If your using an overlay or API on top of a cloud or service, its the overlay's responsibility to ensure a consistency with your expectations. The API is consistent with the UI.

While other cloud providers accept the time that this takes as non-billable, DO don't. By getting higher utilization is how they are able to offer their prices and still have some modicum of service.

View on HN

Let's be clear about what this is: they are charging their customers after their customers have deactivated a service (destroyed a VM) to not create the situation wherein they give that data to another customer later.

What sort of mental gymnastics are required to make that a reasonable choice?

If the hardware is spending its cycles on your workload, then it definitely makes it a reasonable choice. Its not like they can sell those cycles to someone else until your job is done.

Besides we are not talking about a high margin business here. $5 vms when most providers are charging 4x times that. Its not unreasonable to expect that your going to have to pay for extras. Similar to a budget airline, you get what you pay for. You want a service that includes that cost in your other fees... then use AWS, rackspace or one of the 1000s of others.

The basic offerings should be secure. You shouldn't have to know what all the bits and pieces of a custom interface mean before you start using a service in order to use it safely.

Seriously, there should not be an option "Shall we pass your latent information onto the next user?" left active by default. If people want to save that trivial amount of money, then let them turn off safety themselves.

If you care about your information I think you should also take responsibility for it. I can't see the point about blaming others for their defaults, it is made quite clear when you destroy a droplet.

Hrm, I should also add that for a $5/month VM, 10 minutes of time is worth $0.0012. And that 10 minutes doesn't require the RAM or CPU component, just the SSD, so it's much cheaper than that in actuality. It's silly to squabble over pricing that low. It would take a million destroyed VMs (at list price) for the cost to be much more than what's in the office's petty cash box, and it's worth it for the security implications, not to mention PR.

>they are charging their customers after their customers have deactivated a service (destroyed a VM)

They are charging their customers for the number of minutes it takes to safely destroy the VM. This is not a charge for something coming 'after'. It's fundamentally a charge for their actual server use, not a bonus fee.

>What sort of mental gymnastics are required to make that a reasonable choice?

They aren't charging for security, they are giving you the option to buy less server time if you don't need security, or handle it yourself by wiping only the sensitive files. There are no mental gymnastics here.

It takes 10 minutes to destroy a 512mb VM?

Looking at their pricing page, it looks like an instance with 512MB RAM comes with a 20GB disk. Depending on host load, IO and process niceness etc, I can see a `dd if=/dev/zero of=...` taking ~10 minutes easily.

I think you hit the nail on the head here: offering the option to buy less server time if you don't need to wipe data is probably reasonable.

Now, the problem here is that DO turned that choice around, and are therefore not providing security by default, but offering you the option to pay more to get it.

Additionally, this is poorly advertised (the API docs do not clearly state "Your data may be accessible by other users!"), and that explains why many customers are (reasonably) a bit pissed at DO.

Yeah, they screwed up the default via the API, but the choice is a reasonable one to have.

Please see my post debunking everything about DigitalOcean's need to spend even one minute scrubbing user data. The fact that they are using SSDs makes it extraordinarily cheap for them to scrub customer data using the TRIM command (on Linux: by sending the BLKDISCARD IO command). With that, they can logically zero hundreds of gigabytes of customer data within seconds.

I agree that there are ways to implement this. And perhaps they should (mind you from experience not all SSDs do this properly).

I simple can't blame them for delivering what they say they are going to give me, even if they could have built their infrastructure better.

Where do they say that they will give all of your data to the next customer to occupy your spot if you don't use this option?

I have looked at the UI and the API docs and it simply is not there. The scrub option says that it writes zeroes to your partition, but it says nothing about giving all your data away if you don't do that.

I think the issue of defaults is orthogonal to the issue of billing. For example, they could make scrubbing on by default (or even mandatory) and still bill customers for it. Of course they would have to disclose this.

I completely agree for the UI. For the API I think it is completely fine to have it not as default (In fact I would argue having a boolean controlling an optional action default to false for an API is the most correct action).

In this case one must balance the right API choice with the right security choice. Security wins every time, or at least it should, so the default should be wiping. If one would insist on having API booleans default to false, just change the input polarity (e.g. rename "wipe_disk" to "skip_wipe").

Fail safe. Fail safe. Fail safe.

It's fine to make this optional. But it needs to have large flashing red warning lights all around it and it needs to be off by default.

Yes I can't believe people are flipping out over a Fog issue. If you care about the privacy of your data, it is your responsibility to make sure it gets erased. If Fog wants to put that as a default, sure do it.

Actually thinking about this more, I am starting to understand the outrage. I think the commenters are right, it should be secure by default.

Reply on news.ycombinator.com