Mildly Infuriating

Agreed.

Yep. I try to be the change. When I see something that's entirely preventable, I try to invest the time, mostly for my own sanity, to correct the issue, and reduce the frequency of the issue.

I'll put in small scripts on servers to quietly restart problematic services at 4 AM daily so that we don't have to go and do it manually, I'll develop login scripts and such that set a user's environment variables to what they prefer, stuff like that... I'll even run full systems reports from a remote PowerShell script running as an admin that emails me if anything isn't as expected, so I can investigate long before the user even knows there's a problem.

I've pushed for network monitoring by SNMP with sensible alerting, and often, I'll sign in for the day and the first thing I'll check is if any servers are down. Strangely, it's happened.

I want to know about the problem before it's a problem. I want to be able to fix that problem before anyone knows the problem exists.

Given that the op is taking about an apple device, Apple has made their own mobile device management system (MDM) for their devices. Within that MDM you may, or may not be able to set that updates are automatically approved. I'm not certain as I have limited experience with their MDM. I have used it in the past, but only a very small amount, and never in-depth enough to deal with how that MDM handles updates, or what options are available.

I know from my experience with other remote monitoring and management systems that you can often, especially with Windows, specify some clarifications of updates to automatically approve, or do so manually. It is up to the administrator. You can set the approvals to be automatic for all updates too.... Or, when doing manual updates, you can approve updates for a group of computers, or one computer, or all computers. I imagine much of this is also available from Apple's MDM.

The approval only gives the end user the ability to install the update. Due to the disruptive nature of updates, it is generally up to the end user to finish the process at their convenience. Updates usually involve a system restart, so the thinking is to allow the user to pick when specifically to install it, to minimize disruption to their work.

Some organizations with the IT resources to do so, will approve a batch of updates to a group of test devices (usually the IT staff, if there's no pool of devices that are dedicated to testing), where all applications are run through testing after the update. These unit tests, if you will, are usually designed to give an idea if the update has caused any issues with the software that the users need to use. Not all organisations have the resources to do this, and usually rely on third party testing (usually reports from companies that do this sort of testing, or complaints from the public), and will simply approve the update after a duration of time after it has been available for more than a week or month without complaint.

Every organization is different in this respect.

At the same time, the monitors that inform the notification system may not be aware of the approval status of the update and simply see that an update is released, and that the user does not have it installed. This may be an issue with reporting (eg. The update is installed and it's working with outdated information), or it could be any number of other factors.

It's likely that the MDM and update monitoring are done by completely unrelated systems, unaware of what the other is doing, or what has been set.

In the A scenario, going into the MDM and setting automatic approval would fix the problem. By the time the monitoring solution is reporting and notifying the users about an update, it is available to them.

The B scenario, on the other hand, may not even be possible, as it relies on a link from the monitoring system into the MDM to know if an update is approved. If such a system has the ability to set which version all users should be updated to, then when the update is approved, then the version of software that should be expected on the device can be set to a minimum level and notify the users if they are below that level.

The unit tests are usually done by hand, so the outcome can be evaluated immediately. Rather than rely on an automated system for testing, which may not recognise that a failure has occurred if it is an unknown or unexpected error.

Yes, B is preferred, but not always possible. Often with MDM, you cannot exempt a single system from MDM control for updates, depending on the platform, so usually approval is a required step, hence A being an alternative approach.

I’ll use this analogy: Do you hate seatbelt reminders in cars? It’s the same concept.

AFAIK the government that I pay taxes to doesn't demand seat belt reminders. Instead it fines people for not using the belt. (I'm not sure though; I don't own a car.)

That said, working with your example: the risk associated with not applying a security patch, on typical conditions, is way smaller than the one of not using a belt; one is at worst ransomware and personal data leakage, another is literally losing one's own life (or worse, getting brain damage). So it's apples and oranges.

Even then I think that my view is consistent between both situations:

• The devs / car makers should offer the reminder
• They should instruct users why that feature is there, and why it's a bad idea to turn it off.
• Even then you should be able to deactivate that feature, if for some reason you want to do so.
• Trying to prevent the user / car owner from deactivating the nagging boils down to the devs / car makers stepping over their boundaries, assuming that the user is something lacking human-like rationality, and assuming that there are no reasonable motivations to do so.
• If the software user / car owner causes himself harm by deactivating it, that's their problem. And if they cause damage for someone else, they need to be held accountable for it, no matter their "intention" (whatever this means).

You’re putting a lot of trust in people that just isn’t going to work out well in the long run

You're assuming that I trust people to not fuck it up; I don't.

Instead what I think that, if and when they fuck it up, they should own their actions, instead of effectively being a dead weight for everyone else. "Oh noes, I got a vyrus lol!!!!1" - that's their problem, not mine.

Those who hate it because they already take it seriously, will just figure out how to quiet the alarms/notices and/or move on.

A lot of times, there's no way.