- cross-posted to:
- technology@beehaw.org
- cross-posted to:
- technology@beehaw.org
Software that controls your body should always respect your freedom. This article is a recap of scandals of medical devices, like hearing aids, insulin pumps, bionic eyes, and pacemakers, and what we can learn from them. It’s astonishing: you wouldn’t expect these devices to be run by software in such a way that they can leave you completely helpless.
I can’t with this article… there’s a very legitimate argument to be made here, but instead they are whining that stuff stopped working after an iOS update. If you’re running something life-critical you do not install every single update the moment it comes out.
I couldn’t disagree more with you. If you are running something REAL life critical the moment there is a patch you install it and deploy as fast as possible. And if it contains any severe patch it is even the vendor who recalls all the equipment with service bulletin and advisory letters.
With life critical you don’t wait the bug to appear because It maybe too late to avoid deadly consequences.
No. If you’re working with life-critical systems, you only apply patches that are relevant to you. For example, an implantable insulin pump with Bluetooth capability. If there’s a patch that changes the Bluetooth functionality, but you don’t use that functionality, there’s no point in applying the patch.
Yes you do,
Configuration control is a max in this world and you don’t have the control/ability/power to decide which patches go in or stay out. The vendor, the person who has all the power and knowledge, is the one who decides.
You can loose all your certifications or being held liable for any problem due to that policy.
Not even red hat (certainly not a life critical system) allows a different level of patches/state out of their approved ones
Oh yes, why would I apply a security patch for Bluetooth which I don’t even use, on my life-supporting device which someone else could connect to via Bluetooth without me knowing or noticing?
What you are saying is far from reality. Most patches only state vague stuff like “security” or “Bluetooth”.
How would you know, what those mean? Bluetooth could be “Hey, you can now monitor even more with your app” or “fixed some big holes in the chips security which made it hack able via Bluetooth”.
You say it’s far from reality, but I’m speaking from experience. I was responsible for maritime life safety systems. When those systems were implemented, they were tested and qualified for use. It didn’t matter how many updates came out, if they weren’t qualified, they didn’t get deployed. If I had deployed an update that hadn’t been qualified, it would have put lives at risk, such as by causing issues with ship detection or man overboard alerts not going off.
If you want to get really into it, like the systems that run aircraft and nuclear reactors, look up formal verification.
Okay,so you are talking professional equipment with software patches to be applied by professionals.
The article (and also the comments as I understood them) was about end users updating software themselves. Those are two very different things.
Yes, we also only update needed patches on systems we handle, but as an end user I do not check all updates that I apply on my private PC.
Why would I?
Then we disagree. Think about it, you’re patching the OS so what you now have is an untested configuration, and you’ve replaced a working system to get there, on the theory that you might be preventing an unknown bug in the future.
In one instance the vendor even explicitly recommends disabling OS updates until they have tested them.
Keeping a life critical device up to date sounds necessary, to the contrary.
Not if the existing software functions properly. If there’s a fix in it you need then sure, once the vendor has tested and approved it you should migrate.
Depends if it is internet enabled (which most are now a days). If that patch is for a 0fay exploit I don’t want ransomeware for pacemakers.
I think you’re making a good case against an Internet enabled pacemaker ;-)
There’s a reason why Google and Apple let developers test out pre-release versions of their OSes months before the release. Companies which don’t test their apps out to prepare for new versions are at fault, nothing else.
I agree wholeheartedly, alas we live in an imperfect world. It sounds like you’ve waited for an update or two that took longer than expected.
I’m not arguing that the source code shouldn’t be made public. If someone posses the right skills they should definitely be able to take full control over the devices they depend on to keep them alive. It’s a invasive feeling knowing you depend on a gizmo to not die.
The author of this article is glossing over a lot of steps by implying that open sourcing the apps and firmware is a fix for delays in app store approval or other common problems that are inherent in the software/hardware ecosystem. It not really a flawed argument, it’s just not what I would’ve lead with.
I ran an iPhone for many years and never updated anything at all. The apps were updated automatically.
Edit: Ah, you’re talking about an iOS update. Forgive my lack of reading comprehension. Apps that have been automatically updated have been known to stop working, however.
No worries. I clearly should have articulated my point better. I’m always worried about over explaining or sounding pendantic.
That makes two of us :)