Addendum: Part 1: Ownership and Contracts

[Marcus Brinkmann]

Hi,

this is an addendum to my first note.  It provides one more concern
about the "trusted computing" model, an important clarification of the
nature of my objection, and a retraction on the need for a new design
principle.


Monoculture Of Service

In the "trusted computing" model, it is suggested that all contracts,
by default, use the same mediating agent.  This introduces a single
point of failure into the system architecture.  It also concentrates
social and political power into the hands of the mediating agent,
which can (and will) be abused.

In my model, all contracts have to be established explicitely, and
there is no default mechanism.  This will naturally cause people to
choose a variety of contracts.  For example, many contracts do not
require a mediating agent at all, but the common will can be
implemented by either of the involved parties.  Often, there already
is a suitable, local mediating agent available.


Quantitative Differences Cause Qualitative Differences

My main objection is thus that the pervasive use of the
confined+encapsulated design pattern in the system architecture leads
to a new qualitative difference between the systems.  Every single
contract in isolation may appear innocent.  Their sum creates emerging
behaviour that I consider a threat.

It is an open question to me if the individual contracts indeed are
innocent.  In every civil society, there are some contracts that are
invalid, even if you sign on to them.  Some rights are well-recognized
as inalienable.  If such an inalienable right is contained in the
confined+encapsulated design pattern or not is a difficult question
that requires a much more careful analysis than I have attempted so
far.

However, even if every such individual contract is innocent, my
objection still stands, because it is grounded not in the nature of
the individual contract, but in the cummulative effect if it is used
pervasively in the system architecture.

In fact, it is not hard to see that if we take an individual contract
of the confined+encapsulated sort, it can be straightforwardly
implemented in my model with only one requirement beyond what I have
already planned for: The user would need to be able to create a space
bank that provides encapsulation.  (Some more features are required to
make it possible to create such services automatically without human
inspection, but that is a minor point).  However, the presence of this
feature is a local property of the system architecture, not a global
property.

It is thus difficult for me to understand why it has been argued that
not using this form of contract in the system architecture constitutes
a de-facto ban of the ability to engage in such a contract.  Quite the
opposite, I think that engaging in such a contract is very well
possible with only local, non-intrusive changes to the operating
system to support some very specific functions.  Maybe (I have not
analyzed this) it does not make sense to engage in only one such
contract with limited scope, maybe the very nature of the contract
requires its pervasive use in the system architecture.  If this is
true (again, I do not know if this is true or not), this could be a
first indication that this particular form of contract is not as
innocent as it appears.  


A New Design Principle?

I have suggested before that I have formed a new design principle that
provides a taxometer for the use of the confined+encapsulated design
pattern.  However, after having written my note I do not think that a
new design principle is necessary.

The only decision that has to be made is if the risk of losing the
"substance of ones being", as it applies to the realm of one's
computers, is a security threat or not.  The rest follows quite
logically from standard principles on how to design secure operating
systems.

The substance of my argument can thus be summarized in four simple
words:

Ownership must be secured.


Thanks,
Marcus