Dear Mr. Grimes:

While I can sort of understand your point in the enterprise context, this idea is a total non-starter in the residential and consumer context.

The problem is that your idea would basically kill the concept of independent, small-shop software development, and (maybe this is what you want?) most types of Open Source development as well.

Consider your statement:

"...Trusted vendors such as Microsoft, Sun, Apple, Linux, Red Hat, and OpenBSD..."

The problem is that like many in the Open Source community, I DON'T "trust" many of the entities listed above, particularly Microsoft, Sun and Apple.

Wouldn't it be convenient for Microsoft, for example, to have only Windows-environment software (for example, Windows Media Player) that it "approved of", being able to execute in Windows, whereas competing applications (for example the freeware VLC player, or "Media Player Classic") automatically being shut down by the whitelist as "unapproved"? Who would decide what's "approved" or unapproved? Where's the appeal process, when someone decides to "disapprove" the application that you created, for anti-competitive reasons completely unrelated to whether the software in question is legitimate or malicious? And how would you enforce this model on the many semi-independent software developers in the Open Source community?

Sorry, my friend. This sounds like just another sneaky way of perpetuating the hold of Microsoft over its market, not to mention Apple's hold over the market for iPod / iTunes competitors. It's basically a beautiful idea killed by an ugly set of facts.

[Author responds: Nothing in my article limits use or approval to commercial interests. In fact, I purposely mentioned open source projects (e.g. OpenBSD, Linux) in the article. I hope OSS creates a participating client. And although the talent pool is finite, there should be enough computer security reviewers, and improved tools, to let anything get submitted and approved in a quick fashion. We can get a huge pool of OSS reviewers dedicated to it, if some reviewers only want to review OSS software, but I would hope that each side would help the other. I assure you that my intent is not to limit competition. A rising tide lifts all boats. With all that said, I do realize that putting in place an additional review layer does slow down the process and perhaps might cause more hardship on smaller developers. But I don't know how to otherwise stem the flow of malware. Can you suggest something better? -Roger]

Bit9 has been doing whitelisting for 5 years and has built a database of software intelligence that now caps 6b records.

Checkout this video ... www.bit9.com/flash/demo-parity.php

For businesses, SysInternals had - immediately prior to to being purchased by MS - produced an impressive program that would permit highly granular approvals/disapprovals from an admin console. As I recall the demo, the degree of freedom granted to a workstation could be controlled on an individual / group basis.
While not aimed at the home user, it was a powerful tool that I would seriously have considered buying.
I was surprised that MS, to my knowledge, let it die.
(Of course, it might have prevented an update from being rolled out without permission...)

Roger, what about Comodo's antivirus beta? I believe it has something of a whitelist approach in its design. At least, when it's first installed, it scans your system and treats its state at that moment as a "clean system." Any deviation from that point onward gets a pop-up asking for approval, or for a sample to be sent to Comodo for analysis. This certainly isn't the kind of wide-spread system you detail in your column, but it could be seen as the beginning of a change in thinking for antivirus software.

Okena used to do this, and then got bought out by Cisco, so now Cisco says they can do this. The originators at Okena then formed Bit9, and their new product is out, and looking good. I'd love to hear of other companies who have created these app-whitelisting programs!!

I see a number of issues with a whitelist approach.

One is who watches the watchers? You need a large number of volunteers to vet the code. Who selects these guys? How hard is it for a bad actor to get in that group?

How hard would it be for bad actors to overwhelm the group with program submissions (essentially a DOS attack)?

The biggest problem that I see though is that this would give the big players (MS, etc.) a significant speed advantage. If they have direct access to the database (even assuming no hijinks), they can get their apps approved instantly while the smaller competitors must wait weeks to months for whitelist approval.

[Author responds: I think peer selections could produce enough solid volunteers that a slow down would not occur. There are already many vendors with tens of millions of hash values on legitimate software, so we could preload the database to cover a lot of it. If it took longer than a few days to approve any submitted program, then the project would be a failure. Bad approvers would be spotted early on and removed. Worse case scenario for a small developer is that their product would be ranked as Not Classified or something like that and produce a warning (much like unsigned video drivers do in Windows today. The idea is not to kill the software industry. The idea is to give users who don't know any better some useful information on which to base a decision. - Roger]

Whitelisting is a good start. P2P email, with verifiable senders and a graylisting filter/process, is probably the best way to go.
But that would require dumping Exchange, a huge profit center which Microsoft is attempting to project as the base for ubiquitous communications everywhere: PCs, phones, PDAs, automobiles, defibrillators.... So Microsoft is not likely to lead the way here.

"Legitimate programs would be submitted for approval to an expert community of volunteers to analyze."

The malware vendors already constitute such a community. The major factor in whitelisting that is different from anti-virus architectures, is that few people need a new application immediately after it is first released.

Once it ages by only a week, the chance that it contains malware and has not been detected as such by one of the major vendors is rather nil. If aging is added to the mix, the risks are easier to judge and the required service architecture becomes rather simpler.

It's an intriguing idea. I have qualms similar to those expressed by A Canadian Security Dweeb, but also: it is well known that it's easier to write software than to read it. All of these reviews sound like they'd take a ton of time (and might not catch everything). And what about the Microsofts of the world whose code is proprietary and they don't want anyone else to see it?

[Author responds: For the large development houses (e.g. Microsoft, Apple, Linux, Sun, Novell, etc.), we can let them submit directly to the database, as long as they agree to a policy that follows the rules (e.g. privacy, etc.). If not, many AV vendors already employee highly accurate behaviorial analysis programs that can analyze a program without sifting through its source code. It isn't difficult to run a program and analyze its behavior looking for signs of maliciousness. I (and hundreds of others) do it with our honeypot programs already. Of course much of the risk analysis is where the program or content is developed and released. Does it come for a vendor with a known clean and trustworthy record? Or does it come from the IP space of the Russian Business Network? Or was it released on a free porn site as a codec? Does it use straightforward commands or depend on obscurity? I'm not saying that the issues you bring up aren't valid. They are, incredibly so. I'm just saying we can use technology to our advantage to solve those issues. -Roger ]

Interesting idea, but as is human nature I'm immediately struck with all of its shortcomings. As with the first poster, my immediate thought is the impracticality outside the enterprise. Although some details are missing from your description, it sounds like if I send out my club newsletter in a pdf format, for example, I either need to submit it for review or it'll get flagged by the recipients' email clients (and those who use web-based mail systems will probably never see it, since my experience with these systems is that they all have a "you're too stupid to evaluate this yourself, we decided it's malware, and you can't have it -- nanny, nanny, boo, boo!" attitude).

What kind of delay is it going to have before being reviewed? While a newsletter may not be critical for immediate delivery, other messages and files are. When I send an update to one of my clients, they don't expect to have to wait a day to receive it. And I don't think these security experts are going to be sitting around just reviewing programs all day.

[Author responds: Valid point. Add your own whitelist entries, so everything from the club newsletter is passed without waiting for centralized approval. Today, many vendors already ask clients to put their domains on their anti-spam whitelists, no? Again, worse case scenario is not the content being blocked, unless the end-user wants that behavior. Normally, it just would result in a warning message. But how many end-users would love to hear that the (rogue) Microsoft patch being sent to them wasn't found in the legitimate whitelist? Or that the codec they are being asked to download isn't known to be legitimate? How many of us would like our mothers and fathers to have an instant expert on their side, instead of them installing all the spyware and crap we have to clean up on each visit? Speaking of that, I can't remember how many years it has been since I saw my mother or father in their home and my visit started and ended on their computer cleaning the darn thing up. -Roger]