The vulnerability doesn't pop into existence the second it is publicly announced. It was already there. Everybody was already vulnerable.

At least if it's publicly announced people can take steps to defend against it.

Yes but why not send a single email to the manufacturer before making it public? Does it really hurt so much?

From a "cyberpunk hacker" mentality this only gives you an opportunity to roast the manufacturer if they do nothing. Perhaps even bankrupt them, I don't care. Competition will take their places and hopefully be better.

> Does it really hurt so much?

Potentially yes. The manufacturer may attempt to prevent publication through legal threats or action, which can be annoying and expensive even if you ultimately win. The incentive to be annoying goes down significantly once the disclosure cannot be prevented (because it's already public) and the public is watching (i.e. any action against the researcher has a higher likelihood of public backlash).

It also allows the manufacturer, who is likely more experienced and has more resources, to start PR to downplay the attack.

I generally default to responsible/coordinated disclosure, but I also do my research first. If the company has previously shown undesirable behavior (like the stuff I've described), or I've reported to them previously and didn't like the experience, they'll learn about the disclosure from the news.

That doesn't mean hackers knew about it.

It's like finding out my neighbor doesn't lock his front door at night and announcing it on twitter. I didn't create the vulnerability but I'm helping criminals take advantage of it.

>It's like finding out my neighbor doesn't lock his front door at night and announcing it on twitter.

No, it's like finding out your neighbor sold a bunch of faulty locks to a bunch of other people. There's a difference between information that would benefit only one person (the neighbor in your analogy) and information that would benefit many people (the neighbor's customers in my analogy)

In that case it would be better to inform future customers so they don't buy the faulty lock, rather than throwing together an in-depth tutorial on how to take advantage of the lock. Especially since, unlike a lock, software can be updated to fix the problem.

"There's a known exploit that has yet to be fixed"

But then there's an issue of trust. Without documenting the exploit to the public I suppose no one would believe you.

Nevertheless the consequence of releasing an exploit to the public is that you've also informed nefarious players. Actually it's worse than that. Likely the nefarious players are the only ones paying any attention to stuff like this.

Perhaps what's needed is a trusted third party middleman who can verify an exploit exists without releasing it to the general public?

It's not the researchers responsibly that a vendor is incompetent, frankly. The vendor released something broken, that's their burden to bear, it's not wise to assume that you're the first to find a bug, with that in mind expedient full disclosure is acting with the customers best interests.