Hacker News Reader

Comment by lukev | Hacker News Reader

I mean, to use the same analogy:

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.

View on HN

Has that actually ever happened? Lockpicking Lawyer shows most locks are almost effortless to pick. The same locks sold by the millions to all of us.

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.

Lockmakers don't generally claim that their locks are completely resistant to bad actors, but good lockmakers will sometimes claim they are resistant to specific kinds of attack.

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.

> Has that actually ever happened? Lockpicking Lawyer shows most locks are almost effortless to pick. The same locks sold by the millions to all of us.

Then we need new rules for lockmakers too.

The job of a home lock is not to be completely impervious to picking (or other bypass methods like shimming or drilling). It is to make getting in by defeating the lock harder than getting in by breaking the door or breaking a window to the kind of bad guy that most homeowners in the lock's target market will encounter.

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.

We should really talk about locks on businesses.

A house can have a lighter lock than a bank, and different legal principles apply.

#2 isn’t, practically speaking, true. Ordinary hardware store door locks can be opened in a few seconds (using techniques like “bump keys”). Is that a “design defect” if every professional knows it to be true? Locks get security ratings based (partially) on how long it will take to open them without a key.

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.

Well, it's an analogy and that's where it breaks down, as all analogies do.

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.

That’s why the lock analogy is good, though — not everything protected by software is like a bank vault. Door locks cost a lot less than vault locks, and as the customer I get to choose the appropriate level of security and pay accordingly. Right now as a software customer you don’t pay based on how secure you want the software to be, and the vendor isn’t liable for not meeting your expectations. In the end the customers are going to have to finance all this improved security, it won’t come for free.

I think we're agreeing here. Sane regulation would create a system where liability could exist for certain products, and consumers would have some idea of what they're paying for.

We are agreeing! Just trying to bring out the price differential that will result from a liability regime. We had this explosion of cheap software partially because nobody was paying for security (either with money or with inconvenience). Now it seems like people expect to fix it for free just by passing a law insisting it be so.

The physical lock market is much more mature, and we don’t see “bank vault” security as the median lock, far from it.

> A lock maker may certainly have liability if the lock has a design defect and can be readily opened without a key.

Masterlock has entered the chat.

Reply on news.ycombinator.com