Thursday August 12, 2004

Anticipation and verification [long]

Imagine I'm a Windows PC power user. I buy some new software, perhaps on CD, perhaps via download. I start the installer, answer all the questions, and go off to have a coffee while the installation runs. When I return, the installation is incomplete: not because anything went wrong, but because my firewall software is asking whether I want to allow the installer to connect to the Internet.

What should I say?

Obviously I say "Yes", right? But why do I jump to that conclusion? And should I give the software carte blanche to do any subsequent net access, or not? Clicking OK every time gets ever so tedious, and it's a known product from a reputable vendor. Maybe it's even "Signed by FrobozzCo" - but that only tells me who to call if it breaks....

The fact that this interaction is occurring at all is because there's a human in the loop: me. And I'm fairly savvy about such things. I certainly wouldn't trust a "typical" user to get this right. Whenever my wife (a self-confessed technophobe) acquires new software for her PC, I always install and run it a few times, just to get the firewall settings correct. I've "trained her" to interpret any alert from firewall or antivirus software as a problem, not as a normal operational condition. But since I'm basing my decisions on guesswork, even I sometimes get it wrong (which can result in an urgent phone call to me at work).

Now it would be easy for the vendor to include a step in the installation that told me:

This software will contact registration.frobozz.com once during installation. When you use the product, it will contact update.frobozz.com every week to check for updates; you can disable this behavior via the Edit->Preferences menu. The Tutorial module will also open a web server on your machine on port 6565, but will accept only local connections on this port.

This would allow me to respond to the alerts from my firewall based on knowledge rather than guesswork. In fact, if my firewall were just a bit smarter, I could "lock down" the application so that any network access that violated this pattern would be caught.

But why not go further? Why should I have to train my firewall by responding to alerts? If the application vendor can describe the access patterns in human-readable form, why not include a machine-readable document with the same information? Why not include an installation option to Install firewall rules for this application, with the firewall software displaying its interpretation of the policy to me for approval?

So far, we've been talking about end-user software, with a human owner/operator in charge of a very simple firewalled node. But the same problems exist in commercial software, and as far as I know they aren't really being addressed. (If anyone knows differently, please let me know.) Suppose you want to deploy a new servlet (probably one of the most common situations). Some developer ships over a WAR file to you and departs for the weekend, assuring you that everything you need to know is in the web.xml metadata. Sure enough, there's a bunch of resources defined by <resource-ref> elements, and various <context-param> elements that look vaguely like URLs, JMS topics, JDBC sources. Do any of them require you to punch through the firewall from your web tier network to any other part of your network? Hey, that looks like an "https:" URL: ought you to be worrying about SSL keys? At least the EJB references should be straightforward....

Cut to the chase. Today, most of the intended behavior of a piece of software is buried in the source code. We've put a lot of work into expressing the functional interface to a component (whether it be an EJB, a Jini service, a servlet, or a WSDL-defined web service), but much less into describing its dependencies - what resources it uses, and how it interacts with them. Wouldn't it be nice if the application component metadata described the expected behavior of the component in such a way that "the system" (insert vague hand-wave) could:

• check the metadata for consistency with the operational environment (e.g. to catch an errant reference at deployment time)
• configure firewalls, containers, keystores, and so forth, and even
• monitor the component's behavior to ensure that it only did what it said it was going to do?

Of course, if we think about service dependencies in general.... but I'll leave that for another blog entry.