This is something I have thought long and hard about and as such I have to caveat things by saying this is my opinion and that I am no more informed than any other member of the public or IT community. Having said that, I have done my time as a Windows Developer and even once worked on emulation systems such as Wine. These protections will be coming to all OSs - so Vista, Longhorn, SBS - all of them! I really think this is some of the worst mud slinging I have seen in a long time and much is wrong! So what have I seen in the Press. McAfee and Symantec have complained that they want the ability to ignore the APIs in Vista and bash at the Kernel directly for security services. However, Kernel code has to be signed for the integrity of the system. Microsoft will not stick to the rules above and will gain advantage by using unknown APIs That the security prompts and center can not be turned off That Microsoft is right to make these changes and want to increase the integrity of the system As someone who once worked on a large secure project I recognise the types of controls Microsoft wants/has to put in place on the Kernel - something that has been around since Windows XP 64-bit addition based on Server SP1 (yes it was). When you have a look at all the nasties out there, some (rootkits often) place drivers on the system to do the "hiding" from you. A driver sits in the kernel and can see and change almost anything that goes on in there - if you are compromised in the Kernel, they you are hosed!! You will never know it and your tools will tell you everything is fine. If you allow some people to not obey these rules, then the dishonest ones will not be hindered by it. Yes it can be disabled, but why would you as a user want to turn it off? I even saw someone say that the Kernel is where the holes are, so it is important that rather than fixing the issues, MS was better off leaving it to others. Well, why not have Ms produce a better kernel and then most users would be happy. Second, long, long before I worked for Microsoft...