Comment by conductr
7 months ago
How do you roll back a fatal car accident caused by the faulty update?
Giving user’s control over when the update runs allows them to be in a safe and secure setting when that update happens. Allowing them time, gives them and Jeep the ability to slow roll the update so they can halt it if initial feedback is negative.
I say this as a Mac user who does not allow auto updates for MacOS. I wait a week or so until the chatter validates it as non-breaking. They pushed an OS update several years ago that broke a few things I rely on. So I don’t trust them now, but these things just happen on OS’s with third party software. I expect it. But, I also don’t want to be forced to deal with the headaches immediately. I’d rather let the third parties run updates and advise how to deal, before I have to dive into fixing things. With car firmware, there’s really no excuse for this except poor engineering / processes.
Giving user’s control over when the update runs allows them to be in a safe and secure setting when that update happens
FTFA:
> The buggy update doesn't appear to brick the car immediately. Instead, the failure appears to occur while driving — a far more serious problem
And from the GP upthread:
> There is no way to tell if you received the bad update.
> There is no way to tell if you received the 'fix' either.
Good points, I did miss those. However, if I had this vehicle and I was reading this article today - and had the ability I'm asking for - I would just keep my current version running until they figure this mess out. It's the advantage of letting other people run the updates first, you get to hear about issues before you experience them.
> user who does not allow auto updates for MacOS.
Many security compliances require auto-updates to be on. It's thought of to be a lesser evil, because many (most) users never update their OS/browsers, which is worse.
Well it could be solved on two fronts, you could issue the update and let users know that the update needs to be installed and will be automatically installed if not done by a specific timeframe.
If there are security related updates where the risk is severe then they may auto update.
The point is it’s up to the device owner to make their own risk calculation instead of the benevolent manufacturer
the point was that manufacture is forced to have auto update enabled in name of security compliance. so, this issue needs to be solved by compliance first
2 replies →
> Giving user’s control over when the update runs allows them to be in a safe and secure setting when that update happens. Allowing them time, gives them and Jeep the ability to slow roll the update so they can halt it if initial feedback is negative.
This does not fix any QA process that is broken. And frankly you should not need to update any control unit firmware after it is sold. The fact that they're even doing this is broken.
Unless your Mac is somehow attached to 5000 pounds of metal going 65 on the highway, the same standards should probably not apply.
> going 65 on the highway
Oh you sweet summer child
> The fact that they're even doing this is broken.
The NASA space probes are constantly uploaded with new software that has greatly increased the scope of their mission.
The NASA space probes can’t plow into a minivan with a mom and her 2 kids inside. There’s an entire different risk level here.
10 replies →
on the other hand, if you know your old software is buggy and could cause fatal accident, you release a software update, but for some unknown reasons, the user keeps denying updating software, what would you do ?
In that case you issue a recall, which is the correct way of dealing with potentially fatal manufacturing defects.
Which will be costly. Also, it does not guarantee the user will return your car, right?
5 replies →
> on the other hand, if you know your old software is buggy and could cause fatal accident, you release a software update
No. You test it. And release it if and when it is fully tested. (you know, V-cycle). But we are Agile now and testing is expensive.
You can apply every fancy safety model (V cycle, iso262626, ASIL, MIRSA) and nothing can guarantee you write one-shot bug free software when your software is slightly more complex than just controlling some lights, sensors or actuators.
4 replies →