Hacker News Reader

Comment by wglb | Hacker News Reader

> you are a better person than that

I don't think this is an appropriate way to argue. Sounds like if he disagrees with you, he is somehow below standard.

> It's just...minimal decency, to care about other people.

Alerting folks to the danger that they face is one way to do so. Responsible Disclosure is caring about the vendor, whereas full disclosure gives other people the chance to take action on their own to remove themselves from harm.

As another note, why not argue for Responsible Development? This is where the outcry should be. Flaws in products come about because they are shipped before they are finished.

View on HN

> Responsible Disclosure is caring about the vendor, whereas full disclosure gives other people the chance to take action on their own to remove themselves from harm.

That is true, but you missed the other side of the argument. Coordinated disclosure is preferable also to a part of users/customers. Significant part of them have no understanding or incentive enough to mitigate on their own. So the question the discoverer of a bug then faces is 'how much headstart should I give the vendor and the users that depend on the vendor, before I make this public'? This has no universal answer, it may depend on how long the bug is out there and what kind of users may be harmed. But it is easy to see that a little headstart in terms of weeks is more reasonable than headstart=0, especially for bugs that are out there for years.

> why not argue for Responsible Development? This is where the outcry should be. Flaws in products come about because they are shipped before they are finished.

Flaws are not always due to cutting corners. Some bugs in computers are very unintuitive and it could be years before they manifest. More responsible development seems like a good idea, but again, this ignores the other part of the problem - major group of users do not understand the intricacies of development and are not willing to buy more 'responsible' product, if it is 5years behind the newest trend and costs 5x as much.

What about the flaws that aren't unintuitive? What about the bog standard integer overflows vendors routinely leave in code because they won't pay what it costs to ensure they don't ship them?

So let me get this straight: are you arguing that because some portion of bugs each year is due to vendor negligence, it is OK for us security researchers to make the vulnerabilities public and expose users dependent on the vendor any time we want?

Obviously, yes. Your "some portion of" should read "virtually all".

I answered your question. But you didn't answer my question.

What about the flaws that aren't unintuitive? What about the bog standard integer overflows vendors routinely leave in code because they won't pay what it costs to ensure they don't ship them?

How does that matter? The only thing that matters is the harm that certain types of disclosures will do to average users. It doesn't matter whether a bug could have easily been found before release or not; the bug is there, in the wild, in a position to harm users.

By all means, vendors should be taken to task, and be beaten up even more when a bug was easily avoidable. But a bug's stupidity is completely unrelated to how a user might be harmed by an "irresponsible" disclosure. Giving the vendor their just desserts is secondary to that.

> The only thing that matters is the harm that certain types of disclosures will do to average users

I disagree. This does not account for the fact that malicious actors are likely to exploit these before the vendor fixes them on a schedule that they would prefer to dictate. And all users are not incapable of making alternative judgments about the use of vulnerable technology. Users include my Mom, hackers at small companies, giant corporations who are capable of overnight turning off SMB V1.

The harm to users comes from vulnerable software that the vendors put there in the first place.

Reply on news.ycombinator.com