| HN Mirror

This class of locks sounds a lot like the intro to a video game that says "press start to continue". Imagine your TV is broken so only displays the top half of the image. Are you overriding a lock when you press start, even though you can't see the message? Can I sell you a device that detects the top of the video game and flashes on its own screen "press start to continue"? Absolutely. That is all that's going on here and should be 100% legal.

Reading the lawsuit, though, I'm getting the impression that the safety interlocks on the machine are software-based, not hardware-based. That is, the lock says "door closed" or "door open", and the microcontroller refuses to do anything in the "door open" state. This is in contrast to a hardware lock, where the door closing closes a switch that AC power comes in through. Door open, no power, and completely failsafe.

In the case of software locks, I am sure that monitoring apparatus can break the software interlocks accidentally. I used to work for an ISP and wrote a program that SSH'd to each of our OLTs, and downloaded a ton of data about each customer and sync'd it into our database. (No API except SSH-ing in and typing commands, of course.) This totally broke them after a period of time. One Saturday morning I got a frantic Slack from the CEO "shut it off! all of our OLTs are dead!". (As an aside, I had a slack command to kill the monitoring jobs for exactly this reason... we all thought it was pretty hacky.) After debugging this with the vendor, it essentially turns out that reading data takes a lock, and the watchdog also tries to take that lock, and reboots if it can't within some ridiculous timeframe. (It was actually a little more complex than this, involving two redundant CPUs inside the device going out of sync after not being able to read the other's state for too long, but in the end, it's the watchdog that gets you. Their locks were also implemented wrong; "try to acquire it now, go to sleep for a long time if it fails", rather than being woken up when the lock is unlocked. That's what killed us, we did a LOT of reads, and were probably reading at the exact instant that this thing wanted to do its read to keep the system from rebooting.)

So anyway, in the case of the ice cream machine, this sort of bug is possible. The diagnostic tool is reading the internal state, the "transition to next phase" code runs, fails to get the lock on the door interlock state variable, incorrectly assumes "it's probably locked", and turns on the spinning ice cream mixer of death while someone's hand is elbow-deep in melted ice cream. At the end of the day, software interlocks are evil and have literally killed people before (see Therac-25), and the manufacturer of this machine probably doesn't want liability for bad code they've written. The monitoring device increases the chance of liability, so they want it dead.

I see their perspective, of course, but I still think that "that's too bad" is a fine response to their legal team.