Yes exactly, which is why it should be left up to the user, and who adequately understands their circumstances, to determine how they configure their computer. It is the user who understands their tech level the best and should be left to configure their system as they see fit, including disabling or enabling UAC as they see fit.
Essentially, I have been saying that UAC should not be enabled in every-single-instance of Windows since there are better ways of providing real security and isolation.
The original prompt from @thro implied that it was inappropriate to disable UAC even during initial setup when consecutive admin actions are common and then just enable it later after the initial setup is complete. That implication is there because that was the context in which the original post was in: in a thread for how to solve/troubleshoot small windows issues, and quoted from a post for how to do the initial setup to help users avoid small windows issues later. The post did not comment on the final “day-to-day” configuration of the system.
This is somewhat of a different topic than UAC, more comparable to file permissions in linux. UAC is more about elevating permissions and when/how it should be done.
However, the C:\file.txt is one example of how UAC creates “small windows problems” by breaking even notepad when running in Admin Approval Mode (AAM), while having no security benefits in that mode. Other examples are limiting/breaking Steam voice chat functionality and renaming start menu entries. Since there are no real security benefits while configured enabled in AAM, it might as well just be left disabled: it breaks things without any benefit.
The advice here, except for @thro 's, has been to run as standard user and then use the “run as” functionality after initial setup. @thro has been implying that UAC should always be left enabled, even during initial setup, even when troubleshooting “small windows issues”.
This is incorrect because the “Run as” functionality was already present in Windows XP which did not have UAC at all. UAC was added with Vista.
Therefore the “whole point” of UAC is not elevation because Windows already had an elevation system before UAC, which many sys admins used to great effect. The point of UAC in Vista was “something else”. What is that “something else”? Why did Microsoft implement UAC when the “run as” or “elevation” functionality was already present in their OS? What did they hope to change from the Windows XP days to when engineering UAC and as they implemented it in Vista? What would happen if a user tried to run their Vista OS the same as XP? What was Microsoft hoping to change in that experience?
Maybe a link back from when Vista was first published can tell us part of the real reason why UAC was designed and part of why it was implemented the way it was? Do you get why I went out of my way to find a link from that era now and why information like that is so valuable, especially because it is from 2007?
The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default. Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations. On the other hand, users who want to forgo security in favor of convenience can disable UAC on a system in the User Accounts
It’s important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can’t access the data belonging to another user without having that user’s permission.
Because elevations aren’t security boundaries, there’s no guarantee that malware running on a system with standard user rights can’t compromise an elevated process to gain administrative rights […]
- Mark Russinovich on Windows Vista User Account Control
https://web.archive.org/web/20140402171410/http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx
- Note that, OS security here is not provided by UAC, but rather by the use of a normal use account.
- “Forgoing security” means using an administrative account the same way it was used in the Win XP days which was to run any piece of software that needed some form of admin credentials.
I could give a history lesson as to the exact “convenience” provided by UAC, however UAC being a convenience and explicitly not a security boundary is part of why I recommend disabling it in some environments. It already contradicts @thro 's core claim that it should always be enabled because it does not provide any tangible benefit in environments where actual security boundaries already exist (including data-level boundaries, not just OS ones) or where elevations an inappropriate (AAM mode for example or kiosks).
If UAC provided real OS security, then it should be able to provide some security benefit solely by being enabled. However, that is not the case, when it is run in AAM, where it only produces small windows issues without any increase in OS security. There is also no reason not to use an admin account in some environments (disposable VMs), and what end-users mean by “security” means “data security” not “os security”. The OS is trash. It can just be reinstalled again if needed. What users care about securing is their data, which UAC cannot protect. Telling people to always run UAC without respecting their technical level or environment or context that UAC is disabled/enabled under is what is wrong.
For example, if someone points out different environments or conditions, it would make sense to gain a new understanding that there are numerous ways to configure the system to provide both maximum OS and data security. That would be in contrast to the blind “I drank the marketing coolaid” approach of always leaving UAC even during initial system setup.
(actually serious, fuck that software).