One of the things I notice quite a bit with the customers I work with is that they have this tendency to mitigate the risk of applications breaking by changing as little of the platform as they can.

One of the areas where this strategy is challenged is when security updates aren’t distinguishable from application updates. Such is the case, frequently, with Java. Like all other aspects of the platform, people love to hard code version checks into applications, and the fail if you don’t get precisely what you expected. So, you end up freezing in a version within a Java platform series.

This is problematic for several reasons.

The first is security. Here’s what the Microsoft Malware Protection Center has to say: Have you checked the Java?

The second is, surprisingly, compatibility: Error in Internet Explorer 9: "We were unable to return you to <your webpage>, Internet Explorer has stopped trying to restore this website. It appears that the website continues to have a problem"

As it turns out, some older versions of Java don’t run well with IE9. I won’t go into all of the gory details, but I’ll just sum it up by saying that it is (to me) a completely forgivable error: the developers chose to do something which probably would have been OK with straight C++, but which is against the rules with COM. Since COM is one of the most subtle and complex platforms ever created (as anecdotally indicated by the number of subtle bugs I come across) I’m willing to let that slide, they fixed it really quickly, but it does mean that you have to get a new one.

So, if you are planning an upgrade to IE9 (which I recommend), then you’ll also want to plan an upgrade to Java as well (which I already recommended, but now you have two reasons). You may surface a number of issues with hard coding, but for security reasons, it’s really important to remove those obstacles anyway.

I’ve never had a particular interest in being an actor, but if I ever did end up acting for whatever reason, I have a strategy which I’m pretty sure is going to work: I’m going to be Samuel L. Jackson instead of Chris Jackson. Now, I’m not going to do any mad scientist genetic experiments or anything, I’m just going to say I’m Samuel L. Jackson, and then start making movies.

It’s this very strategy which I see some enterprise customers doing.

Today (yes, it’s Saturday – surprise, I’m a geek on weekends too) I had an email dialog that went something like this:

Hey, app compat guy, I’m trying to write an MSI file to Program Files from a standard user account. Can I do that just by changing the ACL?

Well, from the perspective of the operating system, an MSI is just a file, so yes – if you give yourself permission to do a particular task, you are indeed able to begin doing that task. That’s what we call a tautology.

Ah, fantastic. Because they really think it’s inconvenient in general that standard users can’t write to program files, so changing the ACLs sounds like the ticket. Oh, also, how do standard users then go about running those MSIs?

Wait … what?

Yes, I should always think to ask the intent rather than answering the specific question, because the customer was on a trajectory to open up ACLs across Program Files and was then seeking to figure out how to run MSIs as well.

So, basically the customer wanted to have their users be Local Administrators, but they wanted to call them Standard Users.

Another example: I had a customer who was using the Power Users group. They wanted to get rid of Power Users, but because they didn’t want to address their application compatibility issues, they were going to have to give Standard Users all of the same permissions that Power Users once had.

Again – an example where you want to have users have elevated permissions, but pretend that it’s OK because it has a better name.

The fact that the highest privilege group you belong to happens to be called Users (and have the well-known SID S-1-5-32-545) does not matter at all if you give that group the same permissions that local administrators or power users used to have. Calling the group Users does not give you any of the security benefits of running with true standard user permissions. Calling the group Users does not give you the cost savings of running with true standard user permissions. In fact, it’s precisely the opposite. Because you are, in essence, lying about the true nature of your users, not only do you not get these benefits, you THINK that you do because of the name, and then you don’t fix it! And then people get all kinds of confused when they don’t realize any of the benefits of the security posture they think they have.

I advocate moving a significant percentage of users in the typical enterprise to true standard users. There are all kinds of tools which are new to Windows 7 since Windows XP, which means you don’t need all of the XP tricks of opening ACLs (which makes you not quite a true standard user) any longer. But I also appreciate that, because resolving those issues does take time and expertise, you may have to get there gradually rather than in one big bang. But my recommendation, if you can’t get there completely, is to just be honest about what your users truly are. If some still need administrator rights for a while, that’s OK – but then I would just call them that. Don’t call them standard users, but then give standard users all of the power normally reserved for administrators.

Just having the right name is not enough. For, even if I call myself Samuel L. Jackson, people won’t come to the theater to watch me. They won’t buy my DVDs. And I will never, ever sound cool when I say, “Enough is enough. I have had it with these motherf* snakes on this motherf* plane!”