"No one knows how to make a perfectly safe car, yet there are some car safety problems for which car manufacturers are liable and others for which they are not."

The situation you are describing is that automobile safety is implemented primarily by establishing standards and only secondarily by the existence of liability (though it's important).

Now, if you had a large company that bought cars and modified them, that company would itself have an obligation to do it safely too. And having regulations about that would be an absolutely necessary part of liability and safety.

...we absolutely have discovered some vulnerabilities which can be protected against using certain software development techniques, and I see no reason why software vendors ought not be liable for damages caused by their failure to follow these established techniques.

I would note that the existence of zero-days is absolutely not the most pressing problem of software security. Having a reasonable system of connecting X to Y is far more pressing. You can get in as much trouble with a misconfigured system as with a vulnerable system. But broadly, your point that there should be standards, is good.

> The situation you are describing is that automobile safety is implemented primarily by establishing standards and only secondarily by the existence of liability (though it's important).

Indeed, regulatory standards is what I was hinting at, not just civil liability (although I believe both exist for car manufacturers, and should probably exist for software vendors).

Yes, we desperately need broad but appropriate regulatory standards. Especially, security standards and research should focus on securing infrastructure and infrastructure type resources. The hacked water supply article from just a few days ago was shocking even to cynical me.

Things like institutes that study this situation outside the government itself may be necessary to establish trust at this point.

And you can't make the standards primarily about software vendors.

This sort of analogy, just like its popular variants (e.g. 'how come we can build bridges that don't collapse but windows crashes', etc) falls apart under very superficial scrutiny. For one thing, the failure semantics and modes of physical things are vastly simpler. It's not really a fruitful approach to this discussion.

The point of an analogy is to point out that certain aspects of two things are comparable in a certain context. It's true that there are significant differences between cars and software, like, say, the presence of wheels, but those aren't relevant to the specific point I was making. What is it exactly that makes the development of regulation of car safety so different from the development and (potential) regulation of software security?

It's not the presence of wheels, it's the difficulty of even defining what software operating 'correctly' means. This is a fairly well-understood aspect of software in general, not just the security part - hence everything from the important (e.g. halting problem) to the silly ('software will eat the world'). Software represents models we make up and on top of that, ones we interpret. Cars are not like that. You don't say your car made a mistake when it refuses to start one cold morning. There's essentially universal agreement on the 'semantics' of cars and bridges.

The notion of software operating correctly didn't really come up. We're not talking about regulating the reliability or effectiveness of software, but rather the security vulnerabilities, and I suspect the regulations would treat the seriousness of different vulnerabilities by the actual harm they can do, just like flaws in the manufacturing of cars. And sure, there are still cases where one could argue about whether a certain attribute of a certain piece of software constitutes a security vulnerability or not, but that's okay. Laws aren't mathematical proofs. There is undoubtedly some ambiguity and room for reasonable debate in the specifics of car safety regulations as well.

> You don't say your car made a mistake when it refuses to start one cold morning. There's essentially universal agreement on the 'semantics' of cars and bridges.

Since you mentioned it...I don't know whether this is the case, but I would guess that there might be regulations about the temperatures at which car batteries and other components must be capable of operating at. And, as car automation software becomes more advanced and prominent, I think we'll be discovering that there is not in fact universal agreement on the "semantics" of cars. There is probably already considerable overlap in the subjects of my analogy, for recent self-driving capabilities but also for much older standard things like airbags and anti-lock braking systems.

I'm not sure how the security is different than the correctness. Security is just an aspect of it - the software doesn't do what it's supposed to, in some specific way.

But my broader point was that this analogy is basically what 'can god make a rock so big they can't pick it up' is to a discussion of theology.