(Replying to PARENT post)

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) instead of emailing us about it isn't a very responsible way to disclose it and, there isn't actually a security issue, the fog app wasn't passing the scrub flag. In retrospect, I should have been less of a jerk, but I still think sneak was acting in bad faith in how he went about the whole thing. 10 years later and I still remember how pissed off I was that day, hah.
👤neom🕑2y🔼0🗨️0

(Replying to PARENT post)

Wow, this just confirms my belief.

There is precisely zero circumstance where it is ok to give private customer data to another customer.

The fact that you think it had anything to do with an API or how it is used is all anyone needs to know about it.

The idea that warning your customers of your vulnerabilities is "irresponsible" is only true if you care more about revenues than your customers' security.

👤sneak🕑2y🔼0🗨️0

(Replying to PARENT post)

> there isn't actually a security issue, the fog app wasn't passing the scrub flag

At a certain point a default behaviour can be so bad, and so clearly not what a user would expect or want, that it constitutes a security issue. I would think this _more_ than qualifies.

👤rsynnott🕑2y🔼0🗨️0

(Replying to PARENT post)

> there isn't actually a security issue

The official blog from DigitalOcean is here:

https://www.digitalocean.com/blog/transparency-regarding-dat...

While it does not call it a “security issue” directly, it details several changes to the service to prevent customer data leaking between accounts. That seems to contradict your position that there was no problem.

> 10 years later and I still remember how pissed off I was that day, hah.

I would have hoped that after 10 years you would be able to admit that letting customers read each other’s data was a mistake. The existence of a disk scrub API, the problem being improperly reported, and DO being advertised as “not for production use” are not valid excuses.

👤MarkSweep🕑2y🔼0🗨️0

(Replying to PARENT post)

The fact that you think it should be the customers’ responsibility to make sure that DO doesn’t accidentally give your private data away to unknown third parties is an absolutely minblowing take on this matter.

I’ve been a DO customer for the better part of a decade, but there is no way that I can continue to be a customer with a company that has such a blasé stance toward security and protecting customer data.

If anyone can suggest any alternatives that are not Hetzner, I would be interested.

👤ratg13🕑2y🔼0🗨️0

(Replying to PARENT post)

I do find the claim that "there's nothing irresponsible about full immediate disclosure" to be interesting.

https://github.com/fog/fog/issues/2525#issuecomment-31336855

👤richbell🕑2y🔼0🗨️0

(Replying to PARENT post)

Consider the multiple S3 leaks that caused AWS to change their defaults to block public access and disable ACLs. You could say that since buckets were always default private, any misconfiguration was simply user error and users complaining were doing so in bad faith. Or you could understand the implications and help your customers protect their data.
👤figassis🕑2y🔼0🗨️0

(Replying to PARENT post)

Why on Earth would someone have to opt-in to scrubbing with a flag vs. opting out? That's surprising. Is the flag on by default and they specifically opted out before complaining about it?
👤plagiarist🕑2y🔼0🗨️0