Re: Separate trusted computing designs

[Marcus Brinkmann]

At Wed, 30 Aug 2006 16:06:42 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> The term "owner" has a specific and well-defined legal meaning, and I
> have (in the past) understood Marcus to be using this meaning when he
> uses the term "owner".

Actually, the legal definition of ownership is way too complex to be
useful to me.  I refered to Hegel's definition, which boils down to
exlusive right to possess, use and destroy a thing.  Should be close
enough in practice, certainly good enough to analyse the "trusted
computing" model.

> His position (as I understand it) might be
> captured with two statements:
> 
>   1. The legal owner should be able to read and write every bit of this
>      computer's ram (at any time).
>   2. This right should be inalienable -- it should not be possible for
>      an owner to give up this right in whole or in part.

That's not accurate.  In fact, it does not make sense using my
definitions: Exactly because I am the owner, I am able to alienate
some rights to it for the duration of a contract.  Nobody else beside
me could!

What I have elaborated on in the mail "Part 1: Ownership and
Contracts" is how this process works, and what the consequences are if
ownership is diffused carelessly or under pressure.  I think that
protection of ownership is a security issue, and that's why I consider
"trusted computing" as a security threat.

However, I have, in writing, made clear that I admit such alienations,
called "contracts", in my mail "Addendum: Part 1: Ownership and
Contracts", of which the relevant part I reproduce below.

> > > This aside, I disagree with an assumption that you appear to be making
> > > here. It appears to me that you deny the possibility that a machine may
> > > be contracted on a non-exclusive but isolated basis.
> > 
> > Where does he (implicitely) state that one?
> 
> Marcus has been very clear that his concept of "ownership" is not
> subdivisible. He has explicitly excluded any scenario involving shared
> ownership or any scenario in which "total control" is restricted to a
> subset of the resource/machine.

I have in fact devoted a large part of the discussion to "contracts",
which are exactly about such scenarios.

> Of course, I may not have understood him correctly, or I may be
> mis-applying what he has said.

I think you are confusing what I admit as a possibility with what I
consider to be desirable.  I consider it very desirable to not have my
computer alienated, even in parts.  This does not exclude the
conceptual possibility to do so.  However, there are IMO grave risks
involved, and furthermore I don't see any necessity to do so.

For further explanations, I refer to what I have already written about
this.

Thanks,
Marcus

Relevant excerpt from "Addendum: Part 1: Ownership and Contracts":

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.