However, this seems like a good time to mention the advantages of "LUA" (Limited User Access). Basically, rather than logging into Windows with full control over the computer, it's better to have two accounts: one for installing software and one for everyday use. That way, if you run some dodgy code by mistake, you limit how much damage it can do. Most of my regular readers probably know about this already, but you might find it useful if you're doing tech support for your family; if you think that any of it is unclear, please let me know.
So, this will actually be a short series of posts:
In part 1, I'll explain why it's a good idea to log in as a limited/standard user rather than using an administrator account all the time.
In part 2, I'll provide step by step instructions for setting up separate accounts on Windows XP.
In part 3, I'll discuss problems that can arise when you make the change, and ways to work around them, along with a bit of the history that led up to this.
In part 4, I'll discuss what's different in Windows Vista and Windows 7, particularly the much maligned "UAC" feature.
In part 5, I'll briefly cover a few other technologies that work in conjunction with LUA to protect your computer.
The key issue is that when you run a program on your computer, it can do everything that you can do; this may be more than you intended. Here are a couple of real life examples that happened to people I know.
* Dial up.
Nowadays, most people use ADSL to get online (at least in the UK), but ten years ago it was more common to have a dial-up modem. In this case, someone accidentally ran a program that reconfigured the settings on the modem: instead of dialling a local number for their ISP, they dialled a premium rate number every time they went online, which cost £1 per minute. They could still use the internet as usual, so they didn't discover this change until they got the phone bill at the end of the month for hundreds of pounds.
* Online banking.
Every machine on the internet has an IP address, which is a bit like a phone number. When you type in the name of a website (e.g. "www.google.co.uk"), this gets converted to the corresponding IP address (e.g 126.96.36.199). There are machines called DNS servers that handle this conversion for you, but you can also store names/numbers in a special file on your computer, called a HOSTS file.
Again, someone accidentally ran a program that made some changes to their system configuration without their knowledge. In this case, it added several extra entries to the HOSTS file so that you would be redirected every time you tried to do online banking. For instance, if you typed in www.lloydstsb.com, you wouldn't go to the real Lloyds TSB website; instead, you'd go to the fake website run by the people who created the virus. If you typed your username and password into their fake website, they could then use these credentials to log into the real website and steal all your money! This is a bit more sophisticated than the usual "phishing" emails that claim to be from your bank and try to fool you into clicking a link, because this person still got the fake website even when they typed the address themselves. Fortunately, they recognised that the bank website looked a bit different to usual, so they called me in to investigate and I sorted out the problem before they lost any money.
(The Swedish bank Nordea had a similar problem a few years ago, as reported by ZDNet and discussed by Bruce Schneier.)
The common factor in both cases is that they involve changes to the system configuration, i.e. settings that are shared between everyone who uses that machine rather than being user specific.
As I said above, when you run a program it can do anything that you can do. Conversely, if you can't do something then a program can't do it either, and that gives you a safety net. For instance, if you can't change the phone number in your modem on purpose then you can't accidentally change it by clicking on a dodgy attachment.
In Windows, there are basically two types of user: a standard (or limited) user, and an administrator. (Older versions of Windows had the "Power Users" group too, but that was effectively the same as "Administrators".) A standard user can only make changes that affect them, while an administrator can make changes that affect everyone, e.g. installing new software. Most people always log in as an administrator, particularly on home machines; that's partly because it happens by default when you set up a new computer.
If you run a program that's been infected by a virus, typically the first thing it will do is try to infect all the other programs on your computer. That way, even if you delete the original program, you'll get re-infected when you run another one. Also, this can allow the program to do more damage, particularly in a workplace: if you report a problem to IT, then they log into your computer as a domain administrator (another bad idea!), the virus can steal their privileges and infect the entire network. However, if you run as a standard user then the "Program Files" and "Windows" folders are read-only, so you can't change anything there, and therefore you can't infect the programs in those folders. Ideally, you will only run programs from those folders; I'll come back to that in part 5. However, if you have programs scattered all over your hard drive, e.g. "portable Firefox", then you'll be vulnerable.
If you have separate accounts, you will have to swap back and forth between them, which is a bit of extra effort. For instance, if you get a message saying that there's a new version of Adobe Reader available, you won't be able to upgrade it with your standard account. However, this should be fairly rare; for most people, I'd say that this will happen once a fortnight. So, the security benefits should outweigh the minor inconvenience.
The bigger problem is that some programs don't work properly as a standard user; I'll elaborate on this in part 3. This situation is gradually improving, and in most cases the problems are just caused by sloppy programming, i.e. the programs shouldn't need administrator privileges. The problem is that there's a "chicken and egg" aspect to this: if most people (including the programmers) log in as administrator, then most programs will be written to rely on that, because there's no incentive to do it properly; in fact, the company that makes the software may never have tested it as a limited user, so they may not realise that there's a problem! However, if most programs need admin rights then that means that most people need to log in as admin, and that's probably why Windows gives you admin rights when you set up a home machine. (If Microsoft did it differently, people would probably start complaining that the new version "has broken everything".)
Anyway, there's a snowball effect here: if you log in as a standard user most of the time, and report broken software to the companies that make it, that will make them aware of the problem, so hopefully they'll fix it. In extreme cases, this may involve taking your business elsewhere; if enough people do that, the company will either have to change their strategy or go bankrupt. For instance, I used to use DigiGuide, so for five years I paid for an annual subscription. When I discovered that it required admin privileges, I reported this to the company, but they were rather uncooperative, so I cancelled my subscription and told them why. That may seem extreme, but consider this: if you run a program as administrator, it could turn off your firewall and create a new administrator account (a "backdoor"), which would allow them remote access to your computer and all your files. Do they really need that much power? If not, why do they need admin privileges, and why don't they want to run as a limited user? Come, join the revolution!
I first heard about the LUA concept in Aaron Margosis' blog, so and he has some useful information there. In particular, here are two relevant posts: Why you shouldn't run as admin... and "Zero-day" attacks and using limited privilege.
If you'd like to make this change on your computer, part 2 will tell you how.