This is great to see, much appreciated for the disclosure!

That last one has to be a troll, holy shit.

Sure, I'm all for protection for white hats, although I don't think is at all relevant and don't see this as a particularly prominent practical problem in the modern day.

> If a company has a security hole that leads to disclosure of sensitive information, it should be fined

What's a "security hole"? How do you determine the fines? Where do you draw the line for burden of responsibility? If someone discovers a giant global issue in a common industry standard library, like Heartbleed, or the Log4J vulnerability, and uses it against you first, were you responsible for not discovering that vulnerability and mitigating it ahead of time? Why?

> such fines can be used for rewards.

So we're back to the award allocation problem.

> This creates an actual market for penetration testing that includes more than just the handful of big tech companies willing to participate.

Yes, if you can figure out how to determine the value of a vulnerability, the value of a breach, and the value of a reward.

None of this has anything to do with the story we're commenting on; this kind of vulnerability research has never been legally risky.

You're (thankfully) never going to get a legal framework that allows "white hats" to test another person's computer without their permission.

There's a reason Good Samaritan laws are built around rendering aid to injured humans: there is no equivalent if you go down the street popping peoples' car hoods to refill their windshield wiper fluid.

Yes, and my question is both genuine and concrete:

What proposed regulation could address a current failure to value bugs in the existing market?

The parent post suggested regulation as a solution for:

> Rewards that pay the bills and not whatever big tech companies have in their couch cushions.

I don't know how this would work and am interested in learning.

Absolutely. It's extremely common with small and midsize businesses that don't have any IT on staff.

Because they were placed in a position of trust and failed. Typically, the failure stems from a lack of willingness to expend the resources necessary to prevent the failure.

It'd be one thing if these were isolated incidents, but they're not.

Furthermore, the methods you mention simply aren't effective. Our economy is now so consolidated that many markets only have a handful of participants offering goods or services, and these players often all have data and computer security issues. As for divestiture, most people don't own shares, and those who do typically don't know they own shares of a specific company. Most shareholders in the US are retirement or pension funds, and they are run by people who would rather make it impossible for the average person to bring real consequences to their holdings for data breaches, than cause the company to spend money on fixing the issues that allow for the breaches to begin with. After all, it's "cheaper".

> Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem.

That's sort of make it look worse then, doesn't it? The main issue isn't that subtle. Even the wikipedia mentions it:

> points should always be validated before being relied upon for any computation.

Moreover the paper https://eprint.iacr.org/2015/565.pdf also mentions a few times:

> Algorithm 2 assumes that the input point P is in E(Fp2)[N], i.e., has been validated according to Appendix A

Appendix A:

> The main scalar multiplication routine (in Algorithm 2) assumes that the input point lies in E(Fp2 )[N]. However, since we have #E(Fp2) = 392 · N, and in light of small subgroup attacks [39] that can be carried out in certain scenarios, here we briefly mention how our software enables the assertion...

> then took a car from the lot and drove it home, no I would not be surprised if it fell apart before getting out of the lot.

Congrats, the brakes failed, you caused bodily damage to an innocent bystander. Do you take full responsibility for that? I guess you do.

Now build a security solution that you sell to millions of users. Have their private data exposed to attackers because you used a third party library that was not properly audited. Do you take any responsibility, beyond the barebones "well I installed their security patches"?

> It is well known that while the pure engineering disciplines, those that make cars and planes and boats, mostly know what they're doing... the software engineering industry knows how to produce code that constantly needs updates and still manages to segfault in so much as a strong breeze, even though memory safety has been a well understood problem for longer than most developers have been alive.

We're aligned there. In a parallel universe, somehow we find a way to converge. Judging by the replies and downvotes, not on this universe.

Speaking to US laws, auto manufacturers are required to fix design bugs that cause safety issues regardless of warranty or used status, at no cost to the owner. You may be familiar with the standard name for those fixes, "recalls". It's illegal to sell a vehicle with unresolved recalls, though the government deliberately avoids enforcing that as aggressively as they could.

It's a very different system from software's "NO WARRANTY OF ANY KIND".