Systems that are designed by committees tend to be complex, and complexity is bad for security.

Let’s see why things turn out that way. When many people come to specify something, there is generally a reason for their being there. Participating in a specification project of a committee incurs huge costs. It’s not just the work of the one or more individuals. There are also the travel time and travel costs involved. Membership and participation also costs nice sums, sometimes. People don’t do this just for the heck of it. Even people who have loads of money that they discretionary spend on stuff they like seldom like this kind of stuff enough to spend their money on.

When a person is part of such a standardization process, he is usually sent by someone, and this someone always has some vested interest in how things turn out. Some just want to be there, and “be in the know”. For this, however, they do not need to be an influential part of the specification process. For the most part, the one who funds the participation cares dearly about what the design ends up looking like. He has an agenda.

Put a dozen people with agendas together and seldom will these match. Moreover, since committees usually combine people representing various stakeholders, the agendas are almost guaranteed to conflict with each other.

So now that there are conflicts, how are they resolved? When developers working for a company face a conflict, there is always a manager above them to force his choice. Companies are usually non-democratic. They do not need to be social — they need to be profitable. Committees that are non-democratic, that is, committees that consist of some authority that can just make a decision to the dislike of some of the members, have a chance of getting out of the mess rather easily.

Committees that are democratic usually have a voting process for resolving conflicts. Voting is useful, but a collection of many poll results on individual decisions does not always sum up to a consistent design. It more often doesn’t.

In yet worse cases, the delegates simply figure out that the best approach, that also makes everybody happy, is the sum of approaches. If delegate a wants feature x and delegate b wants feature y, then if we support both features x and y then both delegates a and b are happy. A specification that supports awkward combinations of modes, and an overly wide variety of often-unrelated features, is hard to build securely.

Voting, and the shortcut of accepting all leading proposals, lead the resulting specification into being inconsistent and complex. Complexity, the very opposite of the well known KISS principle, opens the door to lax security and to a design that you just can’t reasonably verify later.

So what is the solution?

If you ask me, it is probably based on a mechanism that can force simple and coherent design decisions, just like in a corporate environment. In a standardization body I think it is best to have a powerful chairman.

In democratic committees today, the chairman is merely a facilitator that makes sure that work is done by the procedures; he does not make decisions on the design itself. He should. The chairman should be elected by a democratic procedure, such as a poll. However, once elected (once per project), he should have the con. The delegates present to him and to the group in an attempt to convince him of what they think is the best approach, while eventually he decides. He is responsible for ending up with a consistent and secure outcome, and he has the facilities needed to make sure it ends up that way. In a sense, it is his specification, and all the people just help him make the right decisions.

Will the specification be biased? — Probably. Will everybody be happy with the outcome? — No. Still, it is better than what we have today. Even if we assume that this chairman will have some affiliation and some agenda, his agenda will be the agenda of the majority who elected him. The resulting specification may thus be a bit biased. However, the resulting specification is also biased today, also towards the favor of the more election-wise powerful group. So we do not make situation any worse in this respect. However, we get a specification that is sound, consistent and secure.

The chairman may be required to swear on oath that he shall only consider the robustness and soundness of the design when making his decisions. This will not make his decisions unbiased, of course, but it will at least make sure that he cannot introduce completely arbitrary decisions without being able to explain his rationale.

Instead of appointing a chairman that may be more favorable to one group over the other, it may be possible, if all parties have enough courage, to appoint a real neutral chairman. Such a chairman would not be affiliated with any of the major players that may have interest in the specification taking this form or the other. This will probably lead to decisions that are neutral. The only problem with this approach is that the group that has more support among the delegates will not like to lose its strength by agreeing to appoint a neutral chairman.