A Pilgrim's Journal

I like brittle software.

Now, what I mean by that deserves some explanation, but whenever I think of ideal software that does a job for me, I think of it as a harmonious blend of the robust and the brittle.

First, the robust. Software needs to check its buffer sizes, check OS error codes, behave defensively and not crash even if given complete garbage as input. This side of the equation is very strongly linked to security. The software should be impossible to use for malicious purposes due to a bug in the code.

Another aspect of robustness is flexibility. It should put the user in control, while defending the user from possible mistakes he might make while learning to use the program, or in just everyday use. It should be hard to use wrong.

The brittle side of software also shows up in its error detection, and is a critical part of putting the user in control. If there is an error, I want to know about it. If the program is not absolutely certain that my data is safe, I want to know. If an attacker is trying to use the program to harm me, I want it to complain loudly and often.

I would rather have the program stop running than harm my data.

Not every program can achieve these lofty goals, but this is the nebulous image my mind creates when I think of ideal software. Some of this comes from my background in writing industrial network firmware, where it was better for firmware to halt completely and go to a known safe state, than to assume it knew what you meant and just let that piston stay on your coworker's arm.

So bringing Postel's Law into the equation, there are places where I definitely do not want my software to be liberal in what it accepts. Take a git repository, for example. If there is any remote possibility of data corruption, I want to know, and I want git to refuse to proceed. Luckily, git does a fantastic job of data integrity, which is one of the reasons I like it so much.

Postel's Law was originally about TCP, and so pertains to communication. Taking TCP as a specific example, and trying to apply Postel's law, let's say that a packet arrives with the entire TCP header shifted by 1 bit. I am no TCP stack expert, but I would be surprised if any TCP stack would be able to parse such a packet correctly. The only logical way of dealing with such a packet would be to look at the existing bits with the header format in mind, try to make sense of the non-sensical data, and send back an error if possible, or drop it on the floor.

How does Postel's Law fix a situation where the very format of the data is not respected?

I can understand if there is a TCP flag that is out of order, or if some unambiguous packet abnormality exists in an incoming packet. But there are only a limited number of such possible error combinations. Things have actually progressed in the opposite direction: TCP stacks have gotten more strict to deal with various attacks, and firewalls are used to strictly guard inbound and outbound traffic.

Being too liberal has a cost. And some costs are so high, they are seen as a detriment to society. Just look at the once-popular open SMTP relay.

Even in places where it would seem obvious that being liberal in what you accept is a good thing, upon further reflection, it turns out to be not so clean cut.

Take for example, a corrupt OpenOffice document. The user definitely wants to open it. Maybe some invalid XML is getting in the way, or maybe the file is only half there. What should OpenOffice do? It should make a best effort at retrieving what data it can, and it should open the file read only. It should also warn the user loudly that the file was corrupt, invalid, and inaccurate. The user needs to know this. This may be a file from an outside source, and so the error is not important. But it may also be the first error the user receives about a dying hard disk, or a bad network, or a corrupted filesystem, and restoring from backup is the next item on the agenda.

So in my frame of reference, Postel's Law, which is also called the Robustness Principle, fits right in, but only to half of my ideal software equation. Yes, be robust in what you accept. Be able to process complete garbage input without crashing. I've heard of people who fed a program's own EXE into itself as test input. It should be safe to use input data as a baseball bat and bludgeon the program without it falling over.

Yet the Brittle half of ideal software doesn't change. It is still as loud as before, warning the user of potential pitfalls and trouble on the horizon, and will refuse to proceed if it can't guarantee his data's safety or determine his intent without ambiguity.

In the end, Postel's Law is too ambiguous to be a useful guide, let alone a law. Those that accept it are too liberal, and those that don't are too strict. :-)