One of the things that I thought about this is that generally, security and orthogonality cannot coexist, or better stated: (level of security) x (level of orthogonality) = constant. A more secure system is going to have multiple checkpoints, which will defeat the purpose of orthgonality (though not the ability of code reuse). Orthogonal code will be less secure because of the lack of interaction between security mechanism.

Go back to the car example: most automatics will not let you start the engine if the car is not in park, which means any orthogonality between the ignition and the transmission is gone. But, because of this, there is an increase in 'security' in that you won't be stripping gears or wearing the engine because of improper usage of either system.

So the problem of security vs orthogonality comes down to the programmer (and possibly job description) to decide where they want to be; in your (Ovid's) case, you want to be ultra-strict, which means multiple checks, which means that systems need to be less orthogonal to make everything work. Someone else might feel that because of multiple programmers that are working on a project, orthogonality is an absolute must, and security measures may fall due to this. There's no right or wrong answer to "how secure is secure" or "how orthogonal is orthogonal"; it's all going to depend where the emphasis is to be placed by the programmer.

So when faced with problems like these, the best way to approach them is exactly how your test case did: you ask a number of people for opinions: since everyone has a different idea where security/orthogonality should be, you'll get a number of solutions that sit along the curve given above, and you can choose a solution that is near the point where you desire.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain