[Worf]

The company can almost always shut down their service until they fix it. They'll lose money and their customers could also lose money if they depend on the service. That's the price they'll have to pay. Otherwise, they should either work frantically 24/7 to fix the vuln or if they can't, they should accept the fact that they've pushed code without any regard for security and bear the consequences.

Why do we need to put up with excuses? If a company has lots of complicated code that would need enormous amount of time to fix, it's on them. They decided to release this code into the wild.

If I publish the vuln publicly, the users would have the option to stop using the software/service until it's patched. If a customer is using a service without caring about security, it's on them. I want to protect the customers who would monitor the news for such vulns and protect themselves.

[jefftk]

How would you apply this logic to something like https://meltdownattack.com ? The vulnerability was in hardware, discovered by companies that make user level software, and mitigated by changes to OS kernels.

[Worf]

Sorry for the late reply. While that's a good example of a vuln that's not "owned" by the affected party and mitigation would be hard to create and distribute, IMO we should still make it public relatively quickly because we can't know whether it has already been discovered by someone else. The public as a whole will likely create countermeasures like patches or workarounds more quickly than a small subset comprising of OS developers and CPU vendors. Personally, I might heavily restrict using JS on random sites or downloading random binaries or scripts (even if they're virtualized), virtualize whatever I can (it seems the 2 previous actions are contradictory, but virtualization could help so why not), separate some data and processes on different physical machines or use a different CPU architecture for some things.