The process so far has been remarkably pain free, but there have been some “interesting” idiosyncrasies. First off, I’ve been quite surprised at the number of games that have worked flawlessly. I was expecting to have major issues, but none so far, with the exception of Asheron’s Call. Annoyingly, the problem with AC isn’t the game itself, it’s with Microsoft’s Gaming Zone software, which insists on modifying files in the C:\Program Files directory.
Aaron Margosis’ blog posts about running as a limited user have been extremely helpful as well.
Having said that, there are some oddities I’ve noticed. First off: There seem to be a lot of applications that “assume” that they know what the user’s going to do. For instance, if you double click on the time in the system tray, it pops up with “You don’t have the proper privilege level to change the System Time”. This is a completely accurate statement, since modifying the time requires the SeSystemTime privilege, which isn’t granted to limited users. But it assumes that the reason that I was clicking on the time was to change the time. But maybe I wanted to use the date&time control panel as a shortcut to the calendar? I know of a bunch of users that call action of double clicking on the time in the taskbar as invoking the “cool windows calendar”, they don’t realize that they’re just bringing up the standard date&time applet. If I don’t have the SeSystemTime privilege, then why not just grey out the “OK” button? Let me navigate the control but just prevent me from changing things.
Similarly, the users control panel applet prompts you with a request to enter your credentials. Why? There are lots of things a limited user can do with the users control panel applet (enumerating groups, enumerating users, enumerating group membership, setting user information). But the control panel applet ASSUMES that the user wants to manipulate the state of the other users. It’s certainly true that most of the useful functionality of that control panel applet requires admin access. But it should have waited until the user attempted to perform an action that was denied before it prompted the user for admin credentials.
From my standpoint, these examples violate two of the principals of designing interfaces that involve security:
1) Don’t tell the user they can’t do something until you’ve proven that they can’t do it.
2) Don’t assume what access rights the user needs to perform an operation.
The date&time control panel violates the first principal. The user might be interacting with the control panel for reasons other than changing the time. It turns out that the reason for this is that the date&time applet violates the principle of least privilege by enabling the SeDateTime privilege, running the control panel applet, and then disabling the privilege. If the control panel applet had waited until the user clicked on the “Apply” button before it enabled the privilege (and then failed when the enable privilege failed), it would have better served the user IMHO.
The users control panel applet violates the second principal. In the case of the users control panel, it assumed that I was going to do something that required admin access. This may in fact be a reasonable assumption given the work that the users control panel applet does (its primary task is to manage local group membership). But the applet assumes up front that the user has to be an administrator to perform the action. There may in fact be other classes of users that can access the information in the users control panel – as an example, members of the domains’ “account operators” group may very well be able to perform some or all the actions that the users control panel applet performs. But the control panel applet doesn’t check for that – it assumes that the user has to be a member of the local administrators group to use the control panel applet. Interestingly enough, this behavior only happens on XP PRO when joined to a domain. If you’re not joined to a domain, the users control panel applet allows you to change your user information without prompting you – even as a limited user. Peter Torr also pointed out that the computer management MCC snapin (compmgmt.msc) does the “right” thing – you can interact with the UI, perform actions (adding users to groups, etc), and it’s only when you click the “Apply” button that it fails. The snap-in doesn’t know what’s allowed or not, it just tries the operation, and reports the failure to the user.
This is a really tough problem to solve from a UI perspective – you want to allow the user to do their work, but it’s also highly desirable that you not elevate the privilege of the user beyond the minimum that’s required for them to do their job. The good news is that with more and more developers (both at Microsoft and outside Microsoft) running as non administrative users, more and more of these quirks in the system will be fixed.
Edit: Thanks Mike 🙂