Please don't buy into the idea that embargoes and coordinated disclosure are sacred. They tend to just reinforce existing power structures, sometimes in an unethical (or at least unfair) way.

I'd expect the incentives to be a bit more complicated than that, and I'm also a bit skeptical that either is all that good of a solution. I'd also like to see how exactly "proactive" and "reactive" are being used here, is it about push vs pull for vulnerability notifications, or about hiring their own security researchers, or... ?

They're an attempt to minimize harm, by getting things patched while minimizing information leaked to blackhats.

Just because giving preference to groups with a better reputation and more market share isn't "fair", doesn't mean it's automatically wrong. Now, if you can show that it actually doesn't help . . .

The faster the information gets out the better.

People are willing to make these assumption because they correspond closer to reality.

Prior to disclosure there will always be the possibility that some users are being exploited without their knowledge.

Therefore disclosure always improves the situation by giving those who could have been exploited without their knowledge the choice to take mitigation steps.

All of the "responsible disclosure" nonsense is just PR by companies who want to avoid the most obvious mitigation, which is for customers to stop using their products.

And what are those mitigation steps?

At every step along the way, there's been a choice of "Well, we could own the hardware and incur overhead costs, or we could trust someone else and pay our share of lower overhead. It'll mean giving up some control, but it'll save us a few bucks."

Or maybe it goes like "Well, we could develop with practices that result in more robust code, but we'd be slower to market."

There's definitely a sidetrack of "If we crank up the clock too much, all sorts of things get wibbly and we can no longer guarantee that the outputs match the inputs, but we don't actually have ways of doing it correctly at these speeds. The press will slam us if we don't keep pace with Moore's law, how could we launch a product with only marginal speed gains?"

And pretty often I think it sounds like "The ops staff says they're overworked and we need to add people or we risk an incident, but Salesman Bob says we can actually fire most of them if we put our stuff in BobCloud."

At every step along the way, someone made a conscious choice to do the insecure thing. The folks with their eye on security were dismissed as naysayers, and profit was paramount. And because these practices became so common, they became enshrined in market norms and expected overhead costs.

> A provider can't dedicate hardware for every single customer.

A provider absolutely could dedicate hardware for every single customer, that's literally how every provider operated before virtualization. It just wasn't as profitable as virtualization.

The story of the Three Little Pigs was supposed to teach about the importance of robust infrastructure. Nobody should be surprised when the wolf shows up. And every pig had the choice to build with sticks or bricks, it would just take more work or cost more.

And I see your message as saying "Are you serious? Build with something other than straw?! But we already own so much straw! All the pigs have straw houses, won't someone think of the pigs?"

Meanwhile the bankrupt brick vendor's assets have been auctioned off, and the wolves are salivating.

Not everyone is all in on cloud infrastructure. What about people who are right now deciding whether or not to move critical data to the cloud? Should their security be compromised by hiding the truth about a known exploit in order to "protect" people less concerned about security who already put their data at risk?

If this vulnerability applies regardless of where it is, what is the mitigation then? Move your machine to where? Your suggestion is not practical and you know it. The right mitigation is one that actually will fix the vulnerability. No one shut down machines and migrated everything to another distro because Debian had a bug in generating private key a decade ago even if the bug was zero-day.

edit: I think the mirai botnet(s) had some sort of power struggle? avoiding propagating knowledge about it prevents it from being easily exploited by more actors.

Embargo is simply a way to make sure the huge, rich cloud providers don't have their reputation tarnished at the expense of everyone else. "Stay with bigco, we fix things before everyone finds about it"

I understand (and agree) that the system admins/owners should also be able to mitigate through knowledge, but it's a dilemma that I think is better resolved by the other solution

(in this case it's apparently a complex issue, but history has shown that there are surprisingly easy to exploit bugs/issues (see heartbleed, shellshock (which was apparently very quickly exploited.))

This guy is not releasing an exploit implementation, he is just pointing to the existence of a potential exploit that has a patch in development. He can't even figure out exactly what it is.

The only people who would be able to code this exploit would be the ones who already figured it out before this guy.

If no one talks about a security problem that makes it disappear

Obscurity actually is a layer of security. The mistake is is when people are dependent upon it.

For your analogy to apply here it would be the manufacturer of the door lock having a master key stolen then not telling anyone about it until they have a new lock for you to buy from them, in the case of a lock I would want to know that the lock is useless even if there was not solution so I can mitigate the risk no simply continue locking it believing it to be secure

The difference is a lock-pick can't exploit 20,000 doors in 20 minutes.