
Transparency Regarding Data Security - chrishas35
https://www.digitalocean.com/blog_posts/transparency-regarding-data-security
======
sneak
> At no time was customer data "leaked" between accounts. This would require
> that a user explicitly not scrub their volume after destroying their server;
> in this instance data would be recoverable and should be considered not
> sensitive.

For fuck's sake, now you're just _lying_.

Not scrubbing has been the default - a user doesn't have to "explicitly not
scrub". A simple unadorned "destroy" api command creates the circumstance in
which the data is not destroyed, but made available to others.

If no customer data leaked between accounts, how was I able to read someone
else's stack traces[1], web logs[2], and customer tokens[3] on a freshly
provisioned VM?

What follows is evidence to directly support the claim that you're lying
through your teeth to save face after having been caught being grossly
irresponsible with your customers' data.

Please start acting like professionals.

[1] [http://i.imgur.com/TMp2kdf.png](http://i.imgur.com/TMp2kdf.png)

[2] [http://i.imgur.com/WLv2qSE.png](http://i.imgur.com/WLv2qSE.png)

[3] [http://i.imgur.com/fJOxRN9.png](http://i.imgur.com/fJOxRN9.png)

~~~
nodesocket
You're being ridiculous. They made a conscious decision to increase
performance and the lifetime of their SSD drives by turning `scrub` off by
default. If you enjoy DigitalOcean's prices (starting at $5), there must be
some balance and optimizations to continue to run a business.

In the control panel, its quite clear, and easy to simply check scrub on. I
agree that this change on the API front should have been articulated. However,
Moisey acknowledge their mistake, let's move past it.

~~~
corresation
No one would intentionally make the choice of having their data shared with
other users, and if that is a business model they rely upon they need to find
another.

This is a profound, never-ever-should-happen gap in data security, and it is
yet another instance where DigitalOcean comes out looking remarkably
amateurish.

Conversationally, I would have expected their hypervisor to have been doing
thin provisioning: That until you write data to a block the block is 0s
(having no provisioning on actual storage). And if you write 0s, that too
isn't actually provisioned on real storage. And when you write actual data,
well that is what the block now contains.

~~~
gizmo686
>No one would intentionally make the choice of having their data shared with
other users, and if that is a business model they rely upon they need to find
another.

Unless they do not care if their data is shared, and would be willing to let
it be shared for a reduced cost.

~~~
corresation
If there were a box that said "share your data" that you had to click, I
cannot imagine the users who would click it. Further no one was ever told that
the value proposition of DigitalOcean relies upon a complete and utter lack of
data integrity.

That is a dishonest angle. It is not in any way how this has been sold.
Further you don't get a discount for choosing not to scrub, but instead
essentially get tricked into it by the magical law of defaults.

~~~
gizmo686
I do not mean to say that it was justified in this particular case. I was
responding to the idea that all products must be secure, even for users who do
not want to pay for the added security. Also, it is not so much that I think a
service should offer a discount for handling your data insecurely (although in
this particular case, the insecure handling is actually cheaper on a per user
basis). Rather, there is a place in the market for products that are not
secure, and therefore do not have to pay to develop and maintain the security
aspects of the service.

------
ak217
The fact that DigitalOcean have no idea how to secure customer block devices
makes me wonder what other security issues they are unaware of.

------
alimoeeny
I am not their customer, but I admire their acceptance of their mistake, "The
second mistake that we made was not notifying our customers that use the API"

------
callesgg
Either digital ocean actually has real SSd disks for each vm or something is
deeply wrong.

A new VM should have a new disk file.

When I create a vm I create a vmdk file that represents the disk. When I
delete the vm I also delete the vmdk file. If I then create a new vm I would
use a new vmdk file.

Apparently that is not the way digital ocean does things, but how do they do
stuff then?

~~~
wmf
This was covered in the previous thread:
[https://news.ycombinator.com/item?id=6983270](https://news.ycombinator.com/item?id=6983270)
DO may not be using file-based storage because it is slower.

