Honestly the fact that it has code that says “under condition X, don’t save the user” is concerning in and of itself. I wouldn’t trust this thing in the first place.
It reportedly checks subscription upon putting the vest on and supposedly won’t turn off mid ride.
And if there’s a bug in that code, you’re fucked.
Safety features should work if everything else fails. Their failure mode can’t be “fuck it, it didn’t work”. Which is directly opposite to the failure mode of a subscription based service.
This is why:
-
The FTC needs to do its job and start outlawing all these obscene subscription business models for things that are rightfully products, not services. Where’s my goddamned First Sale Doctrine, FTC?!
-
Software Engineers working on commercial products need to be professionally licensed, so that proper consequences can be applied for unethical “fail-deadly” designs like this one.
As a software engineer, the thought of my code being responsible for someone’s safety is fucking terrifying. Thankfully I’m not in that kind of position.
From experience though, I can tell you that most of the reasons software is shitty is because of middle or upper management, either forcing idiotic business requirements (like a subscription where it doesn’t fucking belong!) or just not allocating time to button things up. I can guarantee that every engineer that worked on that thing hated it and thought it was fucking stupid.
Licensing would be overkill for most software as it’s not usually life and death. I think in this case since it’s safety equipment it really should have been rejected by NHTSA before it ever hit stores.
This is managements fault, not the engineers fault.
We have to implement the requirements we are given. If we don’t, we get fired and they hire someone else who will do it.
My dad worked for AAA. Once he got a call because a lady’s car errored out and thought she didn’t have her seatbelt buckled mid-drive, so it shut the engine off. On the freeway.
Even without a subscription, failsafes should always fail safe.
Thorium reactors have a cleverly dumb failsafe. If reactor control fails, there’s a plug that melts and drains the contents into a container that’s not fit for runoff neutron generation.
That’s an example of a failsafe that fits its purpose. It’s still possible to fuck it up, but it would take a lot of effort to do so.
Yes, but also from an implementation perspective: if I’m making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:
- checking an external authentication service.
- connected to the internet in any way.
- have multiple services which interact over an API. Hell, even FFIs would be in the “only if I have to” bucket.
It checks the service when booting up before a ride. After that it doesn’t connect to the internet. If you’ve gone past your grace period of 60 days it won’t boot up at all, and it will alert you that the device isn’t active.
Don’t get me wrong, I hate the idea of the subscription but it’s important to have accurate information. Did you even read the product page?
If the customer is dead, they definitely can’t renew.
Who wouldn’t tout your service if it saved them?
But also… why the fuck does this require a sub?
The monthly subscription model leaves me feeling so very conflicted. On one hand, it’s a way to get an important piece of safety equipment for less money up front, which is good—there’s certainly cheaper airbag vests, but there’s more expensive ones, too.
No, no, there’s nothing conflicting here. If you need expensive safety equipment that you can’t afford up front there’s already a solution for that, it’s called financing. There is no upside to this, it’s just unethical, irresponsible, and dumb.
IMO, for a safety system, anything sitting between the device’s sensors (to say it’s time to deploy the safety system, regardless of what it is), and the actual deployment of that safety system, is too many things sitting between those systems. There’s should always be a direct and uninterrupted connection from the safety deployment sensors and the safety deployment system. Nothing in between so the delay in deployment is as close to zero as possible, with no complications that could, in any way, shape, or form, delay or otherwise interrupt the connection between those two systems.
I really wonder what the mechanism for this license model is, I’m sure their engineers are intelligent and there’s no obvious issues, but say, for example, the sensors that trigger the airbag and the airbags deployment trigger, has something like a relay in between. The relay is controlled by a management computing device that has verified the license and so it closes the relay (so everything works). Say, for example, during a crash, one of the first things that happens is that you’re struck with debris, and in that debris is a very small, very powerful magnet. It happens to land, right where that relay sits, and because of where it impacts, it causes the relay to open… Disabling the airbag. You get wrecked because you were hit with a magnet.
I’m sure that is not realistic and they’re not using a magnetic based relay for something like this, but I think it demonstrates the point. Anything sitting between (detect) and (deploy) is a risk to life and limb. That includes, but is not limited to, lines of code, relays, disconnects, computers, electronic lockouts, switches, and buttons. Even significant lengths of wire, more than a few inches could be a problem due to induced current or the risk of them being pulled and/or broken. Ideally, the system for detecting that it should deploy and the deployment mechanisms trigger should be in the same, protected box or chassis on the vest, with nothing in-between to inhibit the signal. IMO, the only good way to do this kind of lockout is to control the arming/disarming of the system, where when the system arms (and therefore ready to be used and secure the life and limb of the user), it checks for the presence of a license, first locally (with a license that has been cached that informs when the subscription is set up expire, if that expiry is after now, then arm), and failing that (expiry is before now), check for a license via a link through the app to the web and/or service provider. Providing useful feedback to the user about the system and whether it has armed correctly and therefore ready to deploy.
Have they done it this way? I don’t know. I don’t trust that they have. I’d rather pay more for a safety system and not have it require a subscription than pay monthly to use the system and potentially have it fail a fucking license check when I need it the most. Bluntly, I don’t trust them to get this right. So fuck this, fuck them, and fuck anyone who supports this with their money. Any company putting a financial condition on the safety of your life isn’t a company that should continue to operate.
All of this is to say nothing of: what happens if the license servers fail? Can’t check in for a new license at renewal time because the servers are fucked… Well, good luck in that crash you’re about to have. 🖕
Fucking idiotic to trust a subscription model with your life.
Imagine you are in an accident and the server go off and you get killed while paying for that?
Financing can have a higher interest. It is not this easy, but also not too hard.
I was hoping that the future would be like Star Trek, a beautiful high tech paradise where we worked our problems out and live in a post-scarcity world. Instead we’re getting Deus Ex, minus the shades and trench coats.
Klim could save a lot of bad pr by just blowing the airbag anyway and sending a bill for the remaining value of the vest after the fact.
But then you’re just financing a vest and that’s not a fancy buzzword that makes the c-suite cream their pants.
