And maybe dim the background, as wel as giving information about the creator of the application and if its codesigned. oh wait, that was too obtrusive and annoying
Not sure if you're being sarcastic about how users feel or about that kind of configuration for UAC, but personally it's one of the many things I dislike when I'm on a Windows computer.
For power users it's annoying and disruptive. For users that might benefit the most from it they quickly learn to press ok always whenever they are prompted for something, no matter what it's asking.
In my opinion, an ideal OS would have absolutly no confirmation dialogs what so ever, but instead it would have unlimited systemwide undo for any action. Look at Gmail vs Microsoft 360 webmail. One is a pleasure to use, the other a pain in the but. Some of that difference comes from dialogs and extra steps in 360 where GMail instead lets you undo.
Add powerful application isolation like in iOS, but make it as simple for the user to pass data between programs as it conceptually is to pipe text from one command to another in Unix, except that you shouldn't have to set up the pipeline first, instead you open a program work on something, pass it to another program work on it and so on. Each program also has an isolated location in the fs for persisting user data but since the only way for one program to access data from another program by the user explicitly sending it over, no application can access something it shouldn't have without the users interaction. So like iOS in that respect also. Of course the user can still be socially engineered into giving some data to a program that shouldn't have it but I don't think it could possibly be worse than what we have today.
There are a bunch of other problems and challenges also that I've not gotten around to consider, but I feel that an operating system like the one I described, if open source under an acceptable license (ISC, BSD, MIT or similar preferably) existed, I'd gladly throw away the portability advantages of POSIX in change for it.
Because since the only way that a program can have access to information is by explicitly handing that info to the program from another program the only place you enter a password is on your login screen.
Login password perhaps (at least plain text version of it), but account info (including cookies) in a browser for example would be accessible, as well as anything on disk.
Let me stop you right there. As a sysadmin, UAC is both effective as it is necessary. I absolutely don't want any application a user can launch with a mere YES/NO prompt but proper secondary credentials, interactively or by some nefarious app spawning other processes, to have the ability to gain an administrative level of access over the local machine. Unless it's absolutely necessary (which in most cases, it's not!).
"Power Users" are, in my experience, an annoyance at the corporate level and especially at home when they bomb their system so badly that it requires reinstalling the OS every few months.
However your other points raise a good standard and I'd like to specifically mention one I really want to see in Desktop OS's. That app sandboxing for every "feature" accessed should be a whitelisted (by asking for permission) endeavor. It should request access to the file system (only for those directories in its specific needs), calendar, contacts, network access, looking into other apps (themselves or their access to the file system), network access, etc.
I find it funny that one of my complaints with my current work environment is that the GP UAC setting for power users is just slightly too low. As a Power User (subclass Developer), I know its my job to not do something stupid (with great power, comes great responsibility, after all) and I happily lean on UAC to do its job and help catch me from some of my own stupidity.
I like the Secure Desktop and its forced context switch and I've worked to train myself that A) as a Power User, if I'm pushed to the Secure Desktop its "Serious Business" and pay attention, and equally importantly B) as a Developer, if my app is pushing to the Secure Desktop and it's not for something critical to system security, I wrote something wrong (or one of the libraries I'm depending upon did), because my non-Power Users should probably never see Secure Desktop prompts in almost all of the apps I write.
I don't particularly want and am not sure I need to input secondary security credentials every time I see the Secure Desktop, but I'm happy with the default options in Windows these days and as a Power User welcome it.
(As for feature whitelisting, I think this is an underappreciated part of the Universal Windows Platform [UWP] still. I'm hoping that as more Enterprises start to see Windows 10 S they will pick up on the platform benefits to the UWP and start to mandate Store/UWP-only development. I think the Appx app model of UWP is a game changer for a lot of Enterprise security and that if some Enterprises weren't clinging so hard to "oldest LTS Windows Microsoft supports" deployments, aka Windows 7 is the current Windows XP, there would be a giant demand for UWP-friendly Enterprise developers that I've not yet started to see.)
I totally agree with you, except that asking users multiple times for their password will increase password fatigue. It may be argued that we could prefer the users to mindlessly click on Yes when a popup arises, instead of mindlessly inputting their password. Another option can be timers on the Yes button (like Firefox does), it blocks a few user interface hijacking attacks and gives the user an opportunity to think before they click.
