Since I was in the technical beta program on Connect and filed bugs, I was lucky enough to get a free license of Windows Vista. Like with the XP x64 beta, we're getting a single license, download only. Which is unlike the regular XP beta, since there we got 5 licenses, and a box. And in the Windows 2000 beta, we got 10 licenses... Hmm, if this trend continues, we're going to have to give licenses to Microsoft at the end of the whatever the next Windows beta will be (Vienna?). :P
After a very slow download, I finally got it and installed the x64 edition, and I'm happy to report it's running fine. Not that that's particularly surprising, considering RC2 also ran fine, so why wouldn't the final?
Thanks to the ISP from hell, Lijbrandt Telecom, I have to use SecureW2 to authenticate myself. After heaps of problems in the early beta, it was finally starting to work in the later ones, and this is still true in the RTM build. The procedure for installing it is complicated: since I use an x64 version of Windows (true for XP too), I have compiled the SecureW2 sources myself using the x64 compiler that comes with Visual Studio 2005. I then copy aa_sw2.dll and aa_sw2_res.dll to the System32 folder, and import registry settings that I previously exported for XP to register it as an EAP method. Then I have to start the Wired Auto Config service (and set it to automatic for future use), after which I can use the properties for the connection to configure SecureW2 itself.
It isn't perfect though; almost every time after authentication you get a "COM Surrogate stopped working" message (doesn't seem to have any ill effects though), and usually authentication fails on login, so I have to disable and enable the connection to get it working. It's a hassle, but about all I can do until Alfa & Ariss release a version for Vista (that would use the new EAPHost infrastructure).
If you use SecureW2 and want to have more details about how to get it working on Vista, let me know.
After that it's driver time. Creative's beta drivers for the X-Fi install without issue, and sound is working. The real test will be to see if the SPDIF passthrough situation has improved any since RC2, but that I probably won't do today.
So far, so good!
The following user account picture is included in Windows Vista:
Some of you may know this already, but I'm a huge cat lover. This image alone is enough reason for me to buy Vista. Seriously, there's not enough cute kittens in software today, it's good to see Microsoft putting in the effort to rectify this injustice.
There's a lot of talk going around on the web about the advantages and disadvantages of UAC, or User Account Control. UAC is a technology in the Windows Vista that limits the privilege level of applications.
If you run XP on a home computer, chances are your user account is a member of the Administrators group. By using an administrator account, any application you run can access the entire system, even potentially malicious applications. A much better idea would be to run as a so-called limited user. Such a user can only access its own account settings, but not anything system wide. A limited user also cannot write to (or delete from) critical areas such as the HKEY_LOCAL_MACHINE registry hive, or the Windows folder. In the Unix world, running as a limited user is common practice.
So why do Windows users still run as administrators? This has two main reasons:
Windows Vista contains technologies to alleviate both points, but this post focuses on the first. UAC is the system that helps with performing administrative tasks. Whenever a limited user in Vista wants to do something that requires administrative rights, UAC will prompt the user for administrator credentials and the user can easily elevate to perform the action.
UAC also does something else however. It also imposes these restrictions on members of the Administrators group. With UAC enabled, even administrators are really limited users in disguise. Only the built-in Administrator account (which is disabled by default in Vista) is exempt from this. The only difference between a limited user and an administrator in Vista is that an administrator doesn't need to type a password to elevate, (s)he can just click "Continue". And it is this that a lot of people object to. They feel that they should be allowed to be real administrators, that they shouldn't need to explicitly allow it every time they want to do something that requires administrative rights.
It's here that the confusion starts. Many people assume that UAC's primary purpose is to alleviate the Dancing Bunnies Problem. Sure, it is definitely one of the goals of UAC and it may even help a little, but it is not the primary purpose of UAC in my opinion. After all, as Larry Osterman says, if the user wants to see the dancing bunnies, he will see the dancing bunnies. It doesn't matter if an extra "Continue" button is in the way.
UAC's true purpose is to achieve the principle of least privilege. This old principle says that nothing running on your computer should have more privileges than it needs to execute its task. In XP, this is not the case, everything you run has the same privileges as your account, and as I explained above, this usually means administrator privileges.
So UAC wouldn't help if an application claims to need administrative rights and can trick the user into agreeing to that. But UAC will protect security sensitive applications that don't need administrative rights. Applications such as Internet Explorer and Outlook or Windows Mail don't need administrative privileges for anything, they just read your mail. Yet in XP, these applications get administrative rights if you have them. Applications such as this are under frequent attacks, and unfortunate as it may be, bugs will be found and exploited with malicious intent.
It's here that UAC helps. In XP, if some code in an e-mail manages to exploit a bug in Outlook to run arbitrary code, this code has the same rights as the user, so typically administrative rights. This means this malicious code can access all your data, all your system settings and files, and can change anything it likes. In other words, you're screwed.
Under Vista, Outlook doesn't specify it needs administrative rights so UAC doesn't ask the user anything, and Outlook will be run with reduced rights. Now the exploit does not have elevated privileges. It can attack your account at best, but your system and applications are safe.
UAC also allows some applications to reduce their privilege level even further. This is called protected mode, and is used by Internet Explorer 7 on Windows Vista (IE7 on XP will not do this since it relies on Vista specific technologies). Using protected mode, IE7 doesn't even have the same unelevated privileges as you, it has even less. So now the exploit code can't even mess with your user account, let alone your system.
That is where the value of UAC lies, and where I believe it will make a real difference. Users will still be users, and they'll still happily elevate anything to see dancing bunnies, but at least they'll be protected against exploits in applications that are not elevated.
Subscribe