Don’t Prohibit what you can’t Prevent

President: I thought that I was the only one authorized to launch those planes!
Head of Joint Chiefs of Staff: Well, Mr. President, It seems that he has exceeded his authority.
The above is a quote from memory of a conversation from the movie Dr. Strangelove.

There is no deep theory here. One should not aspire to security by making things merely difficult for the programmer. Soon enough a subroutine will become available that makes the hard thing easy. This principle is not limited to capability designs. Capability systems seem to follow this principle naturally, however. Rob Jellinghaus even proposes “Exploit what you cannot prevent!”.

An interesting near exception to this is cryptography. By using a long key you make something so difficult that it is prevented in effect. It is wise to limit the use of crypto to where nothing else will do and then to bind it closely to that job where it is essential. This is because the pit falls of crypto are largely different from other security pitfalls and different skills and lore are required to avoid them. Crypto is a different art.

There is a Java product on the market that needs to pass data between the applet and the web site. TCP is the most natural and efficient way. When the fire wall blocks TCP packets as a “security feature”, the application resorts to http. In this case the “security” feature has merely made the application less efficient but contributed no security.

Firewalls are too much designed as if the bad buys won’t write any more code.


See “Voluntary Oblivious Compliance” for a nuanced contrary point with merit. I think these can be synthesized.