{ End Bracket }

Trustworthy Software

David S. Platt

The Authenticode dialog box that users see when they download software from the Internet, asking them if they trust the publisher and want to install the software is, in my opinion, a useless and annoying waste of time that provides no safety whatsoever. If you know which vendor you want to trust, this mechanism ensures that it comes from them. But that's not the main problem users encounter on the Internet. Instead, it's usually, "I never heard of you until I googled for [whatever]; now I'm reading your site and wouldn't mind trying your code, but I have no good way of determining whether to trust you or not." This box doesn't answer that question or even help in any meaningful way.

How can a user possibly know enough to answer that question? He can't, he doesn't, and he never will. Depending on the user to do it properly, and washing our hands of responsibility because he gets it wrong, are not acceptable strategies in today's software environment.

How can we tell a user whether some app he's never seen before is trustworthy or not? Mature industries have solved this problem by delegating the testing to a knowledgeable third party whom customers trust. For example, when you buy food labeled "organic," how do you know that it actually is? Unless you're an expert in food production and spend essentially all of your life examining food, you cannot reliably make such a determination. Instead, you look for the certification seal from an agency you trust to have the specialized knowledge and perform the necessary inspections; for example, Oregon Tilth. This architecture scales up very well. Similar third-party certification programs exist for many qualities that customers value but can't trust a manufacturer's claim for—wood from sustainably managed forests, fair trade coffee, food prepared according to a consumer's religious beliefs. The software industry needs to do the same thing.

Software could be certified either by concentrated or distributed testing. The former requires a high-powered testing laboratory, conceptually similar to Underwriters Laboratories, which certifies electrical appliances in the U.S. It would publish a code of best practices, such as using a language that forbids buffer overruns and requires an acceptable privacy policy. It would then test applications for compliance with these standards and affix its digital seal to those that meet them. The lab would charge for this service, and the vendor would add the cost to the price of the application. Probably the mere fact of having to spend thousands on compliance testing would scare off most bad guys. Perhaps, to gain customer acceptance, the testing agency would offer some sort of insurance policy that would pay if the application turned out to be untrustworthy.

The concentrated model would leave smaller vendors out in the cold because they wouldn't be able to pay the fees. The alternative would be a distributed model, similar to the way buyers rate sellers, and vice versa, on eBay. Customers who install an app could vote on whether it is trustworthy or not, and potential downloaders could examine the results of that vote when making their purchase decision. It wouldn't help the very first users, and it wouldn't be infallible. But it would be pretty good, it would be easy to implement, and it would work for small vendors and even shareware.

The system would have to be structured so that a bad guy couldn't rig it. Perhaps voting would be allowed only by numbered e-mail ballots sent to paid and registered customers. Maybe some public interest software foundation would run it, and maybe eBay or Amazon would donate the software as a sponsor opportunity. Since I am writing a book for users entitled Why Software Sucks, I propose the "Doesn't Suck Seal" for applications that pass. It'll feature a lollipop in a circle with a slash through it. There's no reason that the concentrated and distributed certification mechanisms couldn't coexist.

It's not enough to put these certifications on a Web site that users can look at, since no one ever does that. The final piece of this puzzle is to make the operating system pay attention to these third-party certifications, seamlessly downloading and installing applications that have them, and blocking those that don't. This has to be the job of the OS manufacturers.

Once we have these certification agencies in place, it's easy to have them sign applications and to have Windows check that the signature is valid. That part of the certificate mechanism has always worked properly. We just didn't know who to trust before, and now we will.

David S. Platt teaches programming for the .NET Framework at Harvard University. He was selected by Microsoft as one of their Software Legends. He is the author of nine programming books, most recently The Microsoft Platform Ahead (Microsoft Press, 2004). Reach him at www.rollthunder.com.