Hacker News Reader

Comment by mehrdadn | Hacker News Reader

I mean, I'm not taking a hard position on what they should do, but I know (a) it shouldn't be immediate, and (b) logically one would think the logic would be "never disclose unless you can provide a compelling reason for doing so". I'm open to hearing a compelling reason, in which case I would think they should disclose after waiting a while, but I need to hear one first.

View on HN

The compelling reason is that users have a right to know what they're vulnerable to, and how they can protect themselves, or at least mitigate the risk. Once a patch is released, the changesets get examined, and the binaries get reverse engineered. This happens within days, if not hours. That means if the exploit wasn't known before, it definitely is now; the only thing not disclosing achieves is leaving the people vulnerable to the exploit in the dark. Blackhats and the world intelligence community certainly don't need Google's blog post to figure it out.

> logically one would think the logic would be "never disclose unless you can provide a compelling reason for doing so".

AFAIK the compelling reason is that history shows us that vendors won’t take vulnerabilities seriously enough until they get threatened.

This was "never disclose after a patch was provided". How would they not take it seriously if disclosures still happened when patches weren't provided?

Seeing that Apple is still releasing security patches for phones back to the 4s released in 2011, does that argument really apply here?

https://appleinsider.com/articles/19/07/22/apple-issues-ios-...

It's disclosed so that the customers know what the vulnerability is. Sometimes patching is not the best thing to do for a given situation. Other mitigations might be possible, or it might not even be an issue depending on how the software is used. Criminal researchers might have found this information anyway, so it's only fair to put the customers on an equal footing.

> Criminal researchers might have found this information anyway, it's only fair to put the customers on an equal footing.

Or they might not have, in which case you just gave them a pretty powerful weapon, and it's pretty unfair to customers??

> It's disclosed so that the customers know what the vulnerability is. Sometimes patching is not the best thing to do for a given situation. Other mitigations might be possible, or it might not even be an issue depending on how the software is used.

Are you sure "because maybe you shouldn't the patch" is their logic here? (Which doesn't even necessitate this either, but everything I've seen indicates they want you to patch immediately.)

If you have a popular product then criminals will study the patches and reverse engineer the vulns. If you ship a patch then the vuln is known regardless of a post about it. Refusing to disclose patched issues does not improve security.

Someone already mentioned this. See my reply there: https://news.ycombinator.com/item?id=20567923

Logically, one would disclose as soon as the value of disclosing is larger than the value of non-disclosing. I hope we can agree that after 5 years, the benefit users have due to non-disclosing is near-zero, because virtually nobody will still use the vulnerable version. At the same time, if after 5 years the security gap is still unknown to the public, the value for other security researchers will be very large. So, for mobile phone software vulnerabilities, it is definitely better to disclose after 5 years than not to disclose.

Given that before the patch the value of non-disclosing is certainly higher, and after five years the value of disclosing is certainly higher, there must be some point in time from where on disclosing is the right choice. Therefore, the only question is when to disclose, not if to disclose.

Reply on news.ycombinator.com