
DigitalOcean - Transparency Regarding Data Security - fomb
https://digitalocean.com/blog_posts/transparency-regarding-data-security?1
======
rgbrenner
_At no time was customer data "leaked" between accounts. This would require
that a user not scrub their volume after destroying their server; in this
instance data would be recoverable and should be considered not sensitive._

Is it just me, or is this contradictory? "Data wasn't leaked.. but if it was
it was because you didn't check scrub, so it must not have been important."
These are two completely different things. Even if the data was not sensitive,
it could still be leaked between accounts (which is what happened here).

Kudos for committing to fixing the problem though.

~~~
diminoten
A lot of the talk was theoretical and the examples run were I think all within
a user's own space.

If not though, then you're absolutely right that those are contradictory. If,
even during disclosure, one user's data was made available to another user,
that constitutes a data leak.

~~~
rgbrenner
[https://github.com/fog/fog/issues/2525](https://github.com/fog/fog/issues/2525)

[https://f.cloud.github.com/assets/408977/1820859/8658298e-71...](https://f.cloud.github.com/assets/408977/1820859/8658298e-710e-11e3-867a-f3506838146a.png)

    
    
      These are some of the strings I pulled off the root blockdev 
      - I have no such /var/deploy/chegou, or any of these files. I was
      able to recover someone else's webserver logs from yesterday, as well.

~~~
diminoten
Yep, in that case that's absolutely a leak of user data.

The blog post is factually incorrect on that point, what a shame.

~~~
horseapples
Right now, as far as I can tell, that's speculative on both sides. Simply not
enough evidence to say without corroboration that it's factually incorrect.

------
eridius
* Our first and immediate update is to ensure that a clean system is provided during creates, regardless of what method was taken for initiating a destroy [...] The scrub feature will remain, allowing customers to take an extra level of precaution if they choose to scrub the data after the delete.

What is a "clean system", if not a scrubbed one? And if they're scrubbing
during create, why leave the scrub option in during destroy? I have to assume
that when they say "clean system" they _don 't_ mean a scrubbed one, and that
worries me.

If, as they said, their reason for not scrubbing is because of customers
creating and destroying a lot of volumes during the onboarding process, then
it seems to me the best solution is one that I believe was suggested in the
previous thread. Namely, scrub a volume always whenever it's being used by a
new customer. But if the volume is being reused by the same customer, don't
bother scrubbing (unless requested), as presumably there are no concerns about
leaking information from a user back to the same user.

------
thirsteh
Previous thread:
[https://news.ycombinator.com/item?id=6986155](https://news.ycombinator.com/item?id=6986155)

------
unionizenow
Why not use whole disk encryption in the hypervisor and switch the key between
accounts?

------
diminoten
I've seen the TRIM recommendation pop up a few times, and never with a reply
from DO - is this probably how they're going to handle this, or is there a
possible reason for not using TRIM?

~~~
rgbrenner
TRIM is equivalent to 'mark as free'. there's no guarantee it will zero the
data, and whether it is zero'd depends on the manufacturer/model of the drive.

If that's how they implement it, then I look forward to reading their future
security advisory.

~~~
diminoten
Ah yes, I'm not super familiar with the terminology, a sibling comment to
yours specifies that you'd need to use zdat (zero after TRIM) for what I'm
talking about to be effective.

------
aioprisan
And they forgot to add a date on their security updates. How are you supposed
to know when issues are discovered and subsequently addressed?

~~~
warp
The linked blog post says "Posted on December 30th, 2013", were you referring
to the blog post or something else?

