Q. What does your method do that a limited account wouldn't do?
A. While a limited account is, in most ways, even more restrictive than my method, it does not explicitly deny write access to the kernel, leaving the account vulnerable to privilege escalation exploits. My method, on the other hand, employs a "deny" ACL entry, which takes precedences over all "allow" entries. SQL Slammer demonstrated the inadequacy of a limited account way back in 2003; my method alone has held strong since I devised it in the summer of 2007, defending against nasties like Conficker and Mebroot.
Q. How does your method measure up against Sandboxie?
A. I am firmly opposed to virtual sandbox programs, as a keylogger could run quite easily inside the sandbox and still intercept keystrokes. Proponents of virtual sandbox programs advise users to empty the sandbox immediately before logging into e-mail accounts, bank accounts, or any other accounts which contain sensitive data. But frankly, EVERYONE forgets now and then. And with the World Wide Web running as rampant with threats as it is, I guarantee that somebody out there pays the price for such a slip-up every so often. I do, however, favor policy sandboxes, and would love to see GentleSecurity finally produce the 64-bit version of GeSWall that they have been promising us for the last few years. I won't hold my breath, though.
Q. How does your method measure up against Comodo or ZoneAlarm?
A. I am strongly opposed to HIPS firewalls, which are intrusive to the most savvy at best, and useless to the average user at worst. While some are aware that I support UAC, which only alerts the user when a task requires adminstrative privileges; HIPS firewalls are suspicious of the slightest anomalies, and have historically proven ineffective in the event of an attack during installation of a new program, as users are conditioned to routinely click "allow" and "allow always" in a flurry of alerts to make the firewall "pipe down and get on with it." My method can leave users vulnerable during tasks like printer driver installation, which necessitates either unlocking the kernel or logging into an account that stays unlocked; the good news is that you can disconnect your PC from the Internet before installing the printer (or disconnect your modem from the Internet before installing a wireless printer), which I highly recommend if you are running XP or earlier.
Q. Can your method protect against a rogue antivirus?
A. Usually, but only as long as the user doesn't click any part of the pop-up. A lot of people are used to getting rid of annoying advertisements by clicking the red "X" button in the upper-right-hand corner of the window; what many of them don't realize is that, in a rogue antivirus pop-up, that "X" button is deceptively designed to install the program anyway. And furthermore, modern scareware and ransomware threats have been re-engineered in response to the defensive technologies of Vista SP1, SP2, and Windows 7. Windows XP's successors make it very difficult to access the kernel, so many criminals have been settling for the user profile directories. My advice is to terminate rogue pop-ups with the key combination Alt + F4.
Q. Can your method protect against my noxious brother/cousin/guest users?
A. Probably not by itself; the main purpose of locking the kernel is to foil remote exploits (malicious software that is installed automatically and surreptitiously when you visit a hostile/compromised Web site, and sometimes simply when you have an active Internet connection). An even safer practice is to employ my method in a limited account. If this is too restrictive for you, then setup such an account for other users, and password-protect your own account as well as the Administrator. This way, they will be protected from remote attackers as well as themselves.
