[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Separate trusted computing designs

From: Christian Stüble
Subject: Re: Separate trusted computing designs
Date: Thu, 31 Aug 2006 18:47:27 +0200
User-agent: KMail/1.9.1


I am sure I am wrong or maybe it is because I have not yet read your emails 
completely, but I have currently the feeling that someone who has full 
ownership about a PC cannot sell it anymore, because this would violate
the second statement? (it should not be possible for an owner to give up this 
right in whole or in part)

First sale, however, is imo an important right of the user.


Am Donnerstag, 31. August 2006 16:45 schrieb 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.
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]