[JumpCrisscross]

> It's a really hard problem

Hard problems are usually collective-action problems. This isn't one. It's a tragedy of the commons [1], the commons being our digital security.

The simplest solution is a public body that buys and releases exploits. For a variety of reasons, this is a bad idea.

The less-simple but, in my opinion, better model is an insurance model. Think: FDIC. Large device and software makers have to buy a policy, whose rate is based on number of devices or users in America multiplied by a fixed risk premium. The body is tasked with (a) paying out damages to cybersecurity victims, up to a cap and (b) buying exploits in a cost-sharing model, where the company for whom the exploit is being bought pays a flat co-pay and the fund pays the rest. Importantly, the companies don't decide which exploits get bought--the fund does.

Throw in a border-adjustment tax for foreign devices and software and call it a tariff for MAGA points.

[1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons

[impossiblefork]

I think what is actually the problem is the software and hardware manufacturers.

Secure use of any device requires a correct specification. These should be available to device buyers and there should be legal requirements for them to be correct and complete.

Furthermore, such specifications should be required also for software-- precisely what it does and legal guarantees that it's correct.

This hasn't ever been more feasible, also considering that we Europeans are basically at war with the Russians, it seems reasonable to secure our devices.

[Veserv]

We have already have that: ISO 15408, Common Criteria [1]. Certification is already required and done for various classes of products before they can be purchased by the US government.

However, large commercial IT vendors such as Microsoft and Cisco were unable to achieve the minimum security requirements demanded for high criticality deployments, so the US government had to lower the minimum requirements so their bids could be accepted.

At this point, all vendors just specify and certify that their systems have absolutely no security properties and that is deemed adequate for purchase and deployment.

The problem is not lack of specification, it is that people accept and purchase products that certify and specify they have absolutely zero security.

[1] https://en.m.wikipedia.org/wiki/Common_Criteria

[impossiblefork]

Yes, but consumers buy, for example, graphics cards with binary blobs and are certainly not sent a specification of the software in them, or of the interfaces, etc. and that is what I believe is the absolute minimum foundation.

So I mean an internal specification of all hardware interfaces and a complete description of software-- no source code, but a complete flow diagram or multi-process equivalent.

[JumpCrisscross]

> These should be available to device buyers and there should be legal requirements for them to be correct and complete

You're still left with a massive enforcement problem nobody wants to own. Like, "feds sued your kid's avourite toy maker because they didn't file Form 27B/6 correctly" is catnip for a primary challenger.

[clippyplz]

That's an incredibly tough sell, particularly for software. Who is it that should "require" these specifications, and in what context? Can I still put my scrappy code on Github for anyone to look at? Am I breaking the law by unwittingly leaving in a bug?

[impossiblefork]

Yes, but you wouldn't be able to sell it to a consumer.

They way I imagine it: no sales of this kind of thing to ordinary people, only to sophisticated entities who be expected to deal with the incompletely specified source code, so if a software firm wants to buy it that's fine, but you can't shrink wrap it and sell it to an ordinary person.

[joshfraser]

Modern software is layers upon layers of open-source packages and libraries written by tens of thousands of unrelated engineers. How do you write a spec for that?

[fluoridation]

A tragedy of the commons occurs when multiple independent agents exploit a freely available but finite resource until it's completely depleted. Security isn't a resource that's consumed when a given action is performed, and you can never run out of security.

[JumpCrisscross]

> Security isn't a resource that's consumed when a given action is performed, and you can never run out of security

Security is in general non-excludable (vendors typically patch for everyone, not just the discoverer) and non-rival (me using a patch doesn't prevent you from using the patch): that makes it a public good [1]. Whether it can be depleted is irrelevant. (One can "run out" of security inasmuch as a stack becomes practically useless.)

[1] http://www.econport.org/content/handbook/commonpool/cprtable...

[fluoridation]

>Security is [...] a public good

Yeah, sure. But that doesn't make it a resource. It's an abstract idea that we can have more or less of, not a raw physical quantity that can utilize directly, like space or fuel. And yes, it is relevant that it can't be depleted, because that's what the term "tragedy of the commons" refers to.

[jrussino]

> it is relevant that it can't be depleted, because that's what the term "tragedy of the commons" refers to

I think you're using an overly-narrow definition of "tragedy of the commons" here. Often there are gray areas that don't qualify as fully depleting a resource but rather incrementally degrading its quality, and we still treat these as tragedy of the commons problems.

For example, we regulate dumping certain pollutants into our water supply; water pollution is a classic "tragedy of the commons" problem, and in theory you could frame it as a black-and-white problem of "eventually we'll run out of drinkable water", but in practice there's a spectrum of contamination levels and some decision to be made about how much contamination we're willing to put up with.

It seems to me that framing "polluting the security environment" as a similar tragedy of the commons problem holds here, in the sense that any individual actor may stand to gain a lot from e.g. creating and/or hoarding exploits, but in doing so they incrementally degrade the quality of the over-all security ecosystem (in a way that, in isolation, is a net benefit to them), but everyone acting this way pushes the entire ecosystem toward some threshold at which that degradation becomes intolerable to all involved.

[JumpCrisscross]

> It's an abstract idea that we can have more or less of, not a raw physical quantity that can utilize directly, like space or fuel

Uh, intellectual property. Also land ownership is an abstract idea. (Ownership per se is an abstract idea.)

[fluoridation]

Land is obviously a finite resource. I don't know what point you're trying to make with regards to intellectual property.

[JumpCrisscross]

> don't know what point you're trying to make with regards to intellectual property

Stocks. Bonds. Money, for that matter. These are all "abstract idea[s] that we can have more or less of, not a raw physical quantity." We can still characterise them as rival and/or excludable.

[skirge]

security maybe considered "commons" but accountables are individual manufacturers. If my car is malfunctioning I'm punished by law enforcement. There are inspections and quality standards. Private entities may provide certifications.

[Always42]

Please no more mandated insurance programs.

[skirge]

insurers can be quite good at enforcing quality standards