It seems like some (most?) of the security vulnerabilities are analogous to things that physical goods manufacturers do not have liability for either.
It seems like some (most?) of the security vulnerabilities are analogous to things that physical goods manufacturers do not have liability for either.
I don't think this is true — just shipping whatever junk you've piled together by some deadline has become frustratingly common. Also note the article has this to say:
Software makers can avoid liability if they prove a defect was not discoverable given the “objective state of scientific and technical knowledge” at the time the product was put on the market.
If you can show that.
1. A lock maker does not have liability if someone uses a battering ram on my door, or if I give a key to the wrong person.
2. A lock maker may certainly have liability if the lock has a design defect and can be readily opened without a key.
I see no problem with holding software liable for the latter category and not the former, provided the liability is proportionate to the value being protected.
Software makers have skated by with poor quality software for a long time, based mostly on the fact that users can't tell the difference. As the field gets more sophisticated and software is relied on for more and more important things, this needs to change.
Perhaps the lock analogy is good, but that means the eventual answer is that software will have security ratings like locks (on a sliding scale, not binary secure/insecure), and you’ll get what you pay for.
A hardware store lock might protect a single shed, locker, or house.
A software "lock" on a critical system is more equivalent in importance to the full physical security system surrounding a bank vault.
The physical lock market is much more mature, and we don’t see “bank vault” security as the median lock, far from it.
Even so of course we know there IS liability for some things and maybe just locks are not a good example.
But then maybe that just means that security itself is not a good example and the authorities are being inconsistent by going after security only in software.
Or maybe it just means the liability should not be just security in general, but responsibility for when you hold something for someone else.
Most other forms of liability are for the safety of an object sold to the public, or it's very basic functionality. If a normal expected use of a lock cuts peoples fingers off, or if it fails to latch at all, not if it is easy to defeat.
On the legal side, "almost effortless to break" is not the same as non-functioning. In many cases the legal purpose of a lock is to establish intent and culpability: you can't aimlessly wander into a locked room, even if it has the world's shittiest Master lock on it. You gotta break the lock to do that. It serves as a semiotic indicator that an area or item was supposed to be off-limits; as a member of society the onus is on you to respect that.
Locks are likely a poor analogy for software engineering.
Then we need new rules for lockmakers too.
Putting too high a security lock on your house doesn't really reduce your break in rate and it can makes it more expensive if you ever lose your keys if the lock is too hard for the locksmith you call to easily pick.
The locksmith may have to drill it, and then you need to replace the lock. If it is a high enough security lock that the locksmith can't get passed it you'll end up breaking a window anyway, and you probably have to pay for at least 1/2 hour of the locksmith's hourly rate for them to have come out to tell you to break a window.
A house can have a lighter lock than a bank, and different legal principles apply.
Masterlock has entered the chat.