[everforward]

I dislike it here because I like Mullvad, but yes, I think it’s fair to go straight to public disclosure.

Someone with likely substantial qualifications put in time to find this. The company is in it for profit (at least partially). What’s fair for the company is fair for the individual. The company can either offer to pay for bugs under the terms they want, hire more security folks to find the bugs themselves, or just accept that researches get to do whatever they want with their findings.

I’d tell Mullvad, but there are companies I don’t respect enough to feel compelled to give them a heads up. Perhaps the author feels that way about Mullvad, it’s entirely within their right to use this to publicly shame Mullvad.

[Tech_User_Stat]

There was a recent discussion about disclosing publicly if the vendor ignores you. https://x.com/ZackKorman/status/2052427327418556679

Those who do bug bounties full-time ignore programs with no rewards. Those who want to gain experience or pad their resume can submit reports to programs with no rewards because they are not as competitive as those with rewards.

Another issue that is often talked about is the size of the bounty. Most are small <$10K so for users in developed countries, it's not sustainable to go full-time. https://www.theregister.com/security/2019/01/15/want-to-get-...

[everforward]

I tried watching that but X either broke their video controls or disabled them so I can’t skip ahead and the first couple minutes are _slow_.

The whole bug bounty thing is a mess, admittedly, but lacking a bug bounty program entirely feels like immediately losing the moral high ground on “you should have told us first”. There’s a lively debate about what bugs are worth, but it’s objectively not $0 for many classes because a botnet developer will buy them for some amount.

Personally, a big part of my view is formed by the educated assumption that security practices will never improve unless poor security becomes a liability. That’s unlikely to happen with “responsible disclosure” because it gets swept under a rug. Immediate public disclosure changes that risk calculus a lot. I think wed see a lot more downward pressure from vendors to their suppliers if $RandomSaaS had to worry about losing their pants because Oracle had a vuln published.

[Tech_User_Stat]

No software is free from bugs. Category of software that undergo extensive verification like aerospace are priced far higher to accommodate the additional QA. If such extensive verification are added to average consumer or even business software, the massive costs will pass down to average users making it too expensive. Security practices need to improve but I don't think 0-day droppers are the answer. Not every threat actor is at the same skill-level. Immediate public disclosure provides them the opportunity to hit endpoints that they would not have hit coz of low skills.

[everforward]

Software is the only field where people will routinely argue producers can’t be expected to make a product that won’t harm its users and I don’t buy it.

The way your argument reads to me is “software as a category has such little utility that profit margins can only be derived from corner cutting”.

The reality of the landscape is that most companies don’t get hacked as the result of an incredible and novel Spectre-esque attack, it’s something bland and entirely preventable.

Eg https://nvd.nist.gov/vuln/detail/CVE-2025-31324

SAP got a CVE because they just flat out didn’t implement auth on an endpoint in an app architecture that will execute files just for being in a certain directory, and also didn’t prevent writing files to executable paths (or maybe that’s how the feature works, not a SAP person). For every 0 day with a novel root, there are like a thousand that are some kind of humdrum “didn’t enforce auth/SQL sanitation/XSS/other well known exploit with comprehensive solutions”.

I do think there are good reasons to withhold some classes of exploit. If a hacker writes a 14 page proof on how to beat some encryption we had no idea was vulnerable, that’s one thing. Getting owned for making an insecure architecture and then not even putting auth over it is a whole other issue.

[Tech_User_Stat]

Now that I've thought more about it, I agree with you. Most companies fall prey to well known exploits that are not that expensive to mitigate.

I think it's mostly ship product faster > secure product first that leads to such insecure architecture. Ideally, security should be incorporated early in the software development life cycle but most start-ups rarely hire a security guy in the initial phases. https://www.reddit.com/r/indianstartups/comments/1r6zwbg/why... They expect the software devs to have that knowledge. But security hardening is a skill that takes time to develop so most devs just focus on feature development.

Even for well-established companies, most security teams are not given top priority. ->https://www.reddit.com/r/ITManagers/comments/1qwnywo/devs_ig... ->https://www.reddit.com/r/cybersecurity/comments/wjypns/does_... ->https://www.reddit.com/r/cybersecurity/comments/1fjnl9j/fed_...

Will immediate public disclosures change the mindset of top leadership regarding security? For some, yes but most will not change because breaches have become too common. They reason if top tech firms like Microsoft or GitHub can suffer breaches and come out on the other side unscathed, they too can survive a major security incident.