I have never seen any user reading a dialog message if it has a button with label "ok", "cancel", "allow" or "next". Including a lot of developers/dev-ops.
If you blindly click buttons you will not accidentally enable a kernel extension.
The accessibility preferences panel appears to accept those synthetic events, however.
As someone who's gone poking around system internals for twenty-plus years... I can tell you that you're very wrong here. I've forgotten about more completely broken operating systems than I care to discuss, but many of them have ended with me poking around and blindly clicking buttons in a vain hope of getting the OS to do what I want it to do which is apparently frequently different from whatever OS producers want me to do.
Not saying that the majority do; or that a dialog is "good security protection". I just don't think it's as useless as you seem to imply.
More developers than sysadmins but definitely not exclusively so. Never underestimate the degree to which people are rushing or not questioning whether their initial diagnosis was correct.
Case in point: uTorrent. Download and "install". You will, generally, get 2 screens that install junk. On one screen you can click "Decline". On another, you can click "Skip". These screens are between all the normal "which folder", "do you accept" and "thank you" screens.
Case in point: Adobe Reader... download it from their website WITHOUT unchecking the "Optional Offers". You then have a Reader with Benefits.
I consider myself "trained" and "knowledgeable" and I occasionally get bit by these... sidecars... included with desired software.
I have no faith that 95% of people know how to sidestep these "landmines". Decline? that means "don't install". Skip? Why would I skip an important part of the installation.
The system security dialogs like the "permissions" dialogs are not like that - I even read the Android permissions dialog (though I realize most people don't, I still think a sizeable chunk of people do, and thus I considered the original claim - that nobody does, not even developers/dev-ops - to be hyperbolic).
Apple users terrify me.
And in the dev version protect the dev mode by some small ritual (like the 7-times tapping on About in Android).
We've had user-based permissions in the mainstream on personal devices ever since XP, and they have totally failed to protect us from anything. It is an utterly broken, worse than useless, backwards model of security for this class of device.
If you think I'm wrong, by all means tell me why instead of just downvoting like some reddit user. I'll happily provide you with a list of all the ransomware that didn't require even a single elevated permission to ruin someone's day.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Better to provide that list without complaining about the downvotes. Even better would be suggesting how you would improve the system.
If that’s what you think about it, then yeah, I agree you should, at least until you cool off anyway.
Unfortunately, a lot of people still use computers instead of iOS devices explicitly because they want more control and power over what the machine is doing. Security is a lot harder to do in this case.
Ultimately, you can't protect a machine from an empowered user. The best you can hope for is to provide guide rails that make it easier to do the right thing, and harder to do the wrong thing.
Meanwhile, here in reality, the general case is what is design something for (you, btw, were describing lowest common denominator programming - a very different thing with a different, tho related, focus).
Understanding what niche you occupy is key to understanding what products and services are designed for you & which are not. Complaining that you are not catered to as a uncommon case in general purpose product is not only fruitless it’s also foolish.
But isn't that scenario "Game Over" anyway? At least installing kernel extensions is a process that is explicit and - importantly - not just another 'trained to ignore' permissions dialog. The alternative would be to prevent the user from ever installing kernel extensions unless they turn off security, and then you are back to square one. At least this way, authorised kernel extensions are taken under protection and not just left lying around for potential modification?
My main frustruation with SIP has been with environment variables starting with LD and DYLD being silently swallowed e.g. `DYLD_SOMETHING_SOMETHING=a env | grep DYLD` gives no output. So if you want to use these variables, or have existing scripts that do, you have to know what the command you are launching is - if it's an executable bash script, then the variables will never make it in.
SIP isn't perfect, and can be frustrating, but it certainly raises the bar for compromising a whole system.