What I would love to see is a reason. Any program that requests elevated privileges should have to state to me why it wants those privileges. It's really frustrating to get this dialog pop up and have no idea what it's doing.

Many programs actually do, to a varying degree. Some programs are very vague but others can be specific. In the article, the virus even explains it: to install additional codecs. It might have even tricked me into thinking that it might need those (maybe they are integrated into quicktime and thus needs those privliages).

Almost any program that does something more advanced stuff then emails needs a helped application which often requires a root password. This is unfortunately true and apple is not very interested in fixing it (because their AppStore is safe and you ought to only use the AppStore because it will be sufficient for all your needs -- at least that's what the geniuses at Apple told me, which is actually good advice for most people but from time to time they need to enter the root/admin password and you can't really educate "normal users" when to enter it and when not to).

On Windows NT you had to press Ctrl-Alt-Delete at the login prompt because that was a key combination that no other application could intercept. Nowadays you work as a non-privileged user but then you have to enter your admin password in various dialog boxes with no way of knowing if its legit (sometimes ubuntu shows you an ugly-looking (i.e. wrong styled) gtk input dialog during updates. But only sometimes. Thats very confusing.).

On the other hand, each desktop application should be able to request root access. And if you trust these applications (e.g. handbrake on macos) you wouldn't bother to press Ctrl-Alt-Delete or do whatever else it takes.

Any good solution for that?

"Full" UAC, also known as actual UAC, moves you to a secure desktop without any other windows (which also prevents a few forms of keylogging). You can't alt-tab into any of your previous applications, either, until the prompt has been dealt with. Faking this requires kernel-mode permissions.

But then again, users will STILL enter the password, giving the app root permission anyway. The warning here would be that the "fake" Handbrake would not have been signed, and blocked by SmartScreen. (They could get a signing cert, and use that, and aware users would have to know it differs...)

I still think the safest way is Windows XP style. Applications do not get root. You cannot give them root. Things that require an administrative password have to be done under the administrative account.

But then everyone ends up using the admin account for everything and all applications run effectively as root.

That's what I always wondered — why it's hard to fake UAC? Surely I can create a full-screen application which won't give away focus with alt-tab (that's very frequent behaviour with bad games).

One software I was/am still working on has an onscreen display(clear always top window ) so I can draw icons and text over a game, it's a pain to alt-tab out of(due to me setting it to constantly check to see if it's ontop, and if not, to set it).

So I would say that it's certainly possible, although I haven't tried specifically to do that to emulate UAC.

Edit: Infact I had a bug at one stage where if I closed the main window, the invisible window would remain running, with no entry in the start bar.

Now I'm becoming a little more concerned, as I could also listen for hotkeys, (such as Ctrl alt delete) and display my own 'secure login' page. Shit

Listening for these hotkeys is kind of pointless. The whole idea of pressing Ctrl + Alt + Del is that, while you can detect the keys being pressed, you cannot prevent Windows to display its interface on top of yours. See https://en.wikipedia.org/wiki/Secure_attention_key That's actually a good mechanism that should be brought back to all modern OS. I wish Android had something similar (well, available physical input keys are limited, but you get the idea)

I would like to hope so, I haven't tried intercepting something like that(I just listen for certain keys), I do wonder if someone more experienced than me could listen for Ctrl and alt, then intercept the delivery, and display their own. (I would 'assume' the system gets first dibs on any keypress, but what if you listened for Ctrl and alt then used a sendkey to upkey the Ctrl and alt, and detect a del key press and then display a fake).

(Sorry, can't test, as I don't have a Windows machine ready)

AFAIK, whenever you get a dialog that asks for your admin password, hit Control-Alt-Delete. If the dialog is a real one, focus stays with that window. If it is fake, a real one pops up on top of the fake one.

In hindsight I have to admit that Ctrl-Alt-Delete of Windows is a good idea. I propose a variant of this:

Introduce some scary red extra button with a key or locker symbol on it which can't be intercepted by applications or by root applications. When the OS needs authorisation, the user is prompted to hit that button, then a truly modal authentication prompt appears which is only dismissed by a second hit of that button or turning off the system.

This system could use different ways of authentication than by passwords.

Additionally users should be trained in only using this way of authentication and no others. The OS offers a secure API to invoke authentication, so that browsers also can use this for web apps. The prompt will look different and display additional information like «Application X wants to do Z», etc.

Edit: some more thoughts and clarification.

Yes, should show the users login photo at the very least...

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.

There is no undo when you're giving access to information.

This malware reads your passwords and sends them to a remote server. How would you block 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.

>anything on disk

Not if the file system is isolated per app as I said.

> For power users it's annoying and disruptive

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.

I think that's what TouchID is supposed to solve.

Maybe not a good idea, but I was thinking it could be cool if they turned on some lock LED in the bezel.