More important than what devs “try”, those patches do often address vulnerabilities…
…however, sometimes, shit breaks. It’s perfectly possible that a specific user does not want that patch, for multiple reasons:
the patch is botched, the dev fucked up, and the user knows it
the patch doesn’t even work on the user’s machine on first place
the patch works fine, but it tanks the performance in an unavoidable way
the patch introduces some bugs due to interaction with something else
addressing the security vulnerability kills a feature that is more critical for that user than the security issue
et cetera.
Devs have no way to know it. And they shouldn’t code software as if they did.
Furthermore, regardless of what they “mean”, this sort of nagging sends a message to the user, that they shouldn’t be allowed to choose the software of their own machines.
It gets worse! This sort of nagging is not present only for security patches. It’s every bloody where. Including things that clearly do not benefit the user, with data harvesting being just the tip of the iceberg.
I mostly agree with all of your points, but I think you’re failing to see the forest for the trees. The vast majority of users are ignorant as fuck about their tech. They couldn’t give a shit about anything other than their own convenience. If the devs allowed everyone to opt out if it meant no longer getting annoying messages, a huge majority of them would do exactly that, caring little for what that actually means in the long-term for their own security and others’ (yes, a vulnerable device is a danger to others, it isn’t always only impacting just that user).
So they opt for this collective, utilitarian approach, despite it meaning less user control. If you don’t like it, get an android device and root it. Again, I don’t disagree with your points, I just thought it worth pointing out the larger picture.
[Note for readers: my top comment was rather off-topic, as I focused on development. OP has two additional layers of complexity - IT bureaucracy and corporate environment.]
I don’t think that I’m failing to see the forest for the trees. I think that the key difference is that I’m not willing to give the stupid a pass to cause harm; and because of that I don’t think that devs should go out of their way to protect those [in your words] “ignorant as fuck” users, even if they’re the majority.
Once the devs provided the security patch, informed the user about it, and informed the user about the consequences of not applying that security patch (in clear and layman-friendly words), their job is done. Going past that to ask the user over and over about it, with no way to turn it off, is 1) patronising, 2) assumptive, and 3) belittling.
Exaggerating it a bit, it’s a lot like someone knocking at your door and asking:
[Person] “If you have knives, I’ll get rid of them for you. You’re assumed to be too disgustingly stupid to not cause itself harm with them.”
[You] “Sod off! I’m not getting rid of my knives. Also if I hurt myself it’s my problem, not yours.”
[Person] “Ah, so you said «maybe later»! Ok! I shall visit you tomorrow and repeat the request. Remember, I care about you~”
If the devs allowed everyone to opt out if it meant no longer getting annoying messages, a huge majority of them would do exactly that
Advanced settings, sane defaults, and automatic updates exist for this reason. If the user is so ignorant that they’re unable to realise why they should at least consider to apply the sec patch, they’re also too ignorant to turn automatic updates off.
yes, a vulnerable device is a danger to others, it isn’t always only impacting just that user
Again, not the devs’ fault. The user shouldn’t be treated as something unable to be held responsible for the harm that it causes. And when they cause someone harm, they should be blamed.
That backtracks to the OP, with the IT nagging the user to update the software but not allowing them to do so. In those situations, the IT shouldn’t be acting like those shitty devs, who think “if you annoy the user enough it’ll obey you”; they should be asking the user/employee why they’re not updating their software, even if it causes a risk for the company.
I’ll use this analogy: Do you hate seatbelt reminders in cars? It’s the same concept. You’re putting a lot of trust in people that just isn’t going to work out well in the long run, as was seen with countless people continuing to ignore seatbelt safety for generations until it was forcefed into the culture. I view cybersecurity reminders the same way, where lots of people ignore it until it’s forcefed into the collective to be taken seriously.
Those who hate it because they already take it seriously, will just figure out how to quiet the alarms/notices and/or move on. Again, I get that you’re essentially saying, “but it’s the principle of the matter!” I just don’t think it’s that big of a deal, as I’d rather be comforted knowing that my friends and family who send me videos/pictures/random crap are doing so from a device that isn’t as likely to be completely compromised.
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.
To be fair, most of the time those updates are trying to patch security vulnerabilities haha
Like iOS and Android both had a few critical CVEs a few months ago that were a really big deal since the vulnerabilities required no user input.
Anyway, those updates are pretty important more often than not and not just meant to annoy you :)
More important than what devs “try”, those patches do often address vulnerabilities…
…however, sometimes, shit breaks. It’s perfectly possible that a specific user does not want that patch, for multiple reasons:
Devs have no way to know it. And they shouldn’t code software as if they did.
Furthermore, regardless of what they “mean”, this sort of nagging sends a message to the user, that they shouldn’t be allowed to choose the software of their own machines.
It gets worse! This sort of nagging is not present only for security patches. It’s every bloody where. Including things that clearly do not benefit the user, with data harvesting being just the tip of the iceberg.
I mostly agree with all of your points, but I think you’re failing to see the forest for the trees. The vast majority of users are ignorant as fuck about their tech. They couldn’t give a shit about anything other than their own convenience. If the devs allowed everyone to opt out if it meant no longer getting annoying messages, a huge majority of them would do exactly that, caring little for what that actually means in the long-term for their own security and others’ (yes, a vulnerable device is a danger to others, it isn’t always only impacting just that user).
So they opt for this collective, utilitarian approach, despite it meaning less user control. If you don’t like it, get an android device and root it. Again, I don’t disagree with your points, I just thought it worth pointing out the larger picture.
[Note for readers: my top comment was rather off-topic, as I focused on development. OP has two additional layers of complexity - IT bureaucracy and corporate environment.]
I don’t think that I’m failing to see the forest for the trees. I think that the key difference is that I’m not willing to give the stupid a pass to cause harm; and because of that I don’t think that devs should go out of their way to protect those [in your words] “ignorant as fuck” users, even if they’re the majority.
Once the devs provided the security patch, informed the user about it, and informed the user about the consequences of not applying that security patch (in clear and layman-friendly words), their job is done. Going past that to ask the user over and over about it, with no way to turn it off, is 1) patronising, 2) assumptive, and 3) belittling.
Exaggerating it a bit, it’s a lot like someone knocking at your door and asking:
Advanced settings, sane defaults, and automatic updates exist for this reason. If the user is so ignorant that they’re unable to realise why they should at least consider to apply the sec patch, they’re also too ignorant to turn automatic updates off.
Again, not the devs’ fault. The user shouldn’t be treated as something unable to be held responsible for the harm that it causes. And when they cause someone harm, they should be blamed.
That backtracks to the OP, with the IT nagging the user to update the software but not allowing them to do so. In those situations, the IT shouldn’t be acting like those shitty devs, who think “if you annoy the user enough it’ll obey you”; they should be asking the user/employee why they’re not updating their software, even if it causes a risk for the company.
I’ll use this analogy: Do you hate seatbelt reminders in cars? It’s the same concept. You’re putting a lot of trust in people that just isn’t going to work out well in the long run, as was seen with countless people continuing to ignore seatbelt safety for generations until it was forcefed into the culture. I view cybersecurity reminders the same way, where lots of people ignore it until it’s forcefed into the collective to be taken seriously.
Those who hate it because they already take it seriously, will just figure out how to quiet the alarms/notices and/or move on. Again, I get that you’re essentially saying, “but it’s the principle of the matter!” I just don’t think it’s that big of a deal, as I’d rather be comforted knowing that my friends and family who send me videos/pictures/random crap are doing so from a device that isn’t as likely to be completely compromised.
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:
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.
A lot of times, there’s no way.