EFF Report on Trusted Computing

Nomen Nescio nobody at dizum.com
Sun Oct 12 22:10:06 PDT 2003


Just thought someone should take the trouble to rebut the anonymous
pro-treacherous-computing rantings...

I have heavily trimmed our anonymous ranters verbose writing style to
keep just the bits I'm responding to (inline...)

> The EFF tries to distinguish between "good" and "bad" aspects of TC,
> but it does not draw the line in quite the right place, even given
> its somewhat questionable assumptions.  

Unsubstantiated claim: what incorrect assumptions did Schoen make?  I
did not see any.

> It fails to sufficiently emphasize the many positive uses of the
> full version of TC (and hence the costs of blocking its
> implementation),

Schoen points out that TC can be broken out into desirable and
undesirable features.  If you omit the undesirable features, as he
describes, you get the remaining desirable features.

There is no loss from blocking the undesirable features.

> And the recommended fix to TC is not clearly described and as
> written appears to be somewhat contradictory.

I see no contradition.  More unsubstantiated claims.

> But let us begin with some positive elements of the EFF report.  This is
> perhaps the first public, critical analysis of TC which fails to include
> two of the worst lies about the technology, lies promulgated primarily
> by Ross Anderson and Lucky Green: that only authorized programs can run
> "trusted", and that unauthorized or illegal programs and data will be
> deleted from computers or prevented from running.  

They are not lying and you do your credibility no favors by making
such unsubstantiated claims.

You are just misconstruing the obvious meaning of their warnings: the
features they describe (and plenty more and worse) are technically
feasible with the TC hardware enforcement, and given microsoft's
history of repeated dirty tricks campaigns in the areas of document
format wars, reporting private information back home to microsoft,
browser wars, interface wars, restrictive business practices regarding
licensing it would be fool hardy in the extreme to not expect more of
the same in the area of platform control based on Palladium.

Of course _you_ are not wishing to admit or emphasize these points,
but you can hardly get away with impugning the integrity of high
reputation individuals like Prof Ross Anderson with such paltry
mischaracterisation.

Your arguments are crass and of the form: "but the current microsoft
PR documents don't admit that it could do that, nor of course that
microsoft are planning to do that, so it's not fair for you to point
that out and caution people about the kinds of things microsoft may be
planning".  Technology is criticized and discussed based on the
potential and most likely inferred directions given microsoft's
history and prior demonstration of interest to control various aspects
of the software platform.

> The report also forthrightly rejects the claim that TC technology is
> some kind of trick to defeat Linux or lock-in computers to Microsoft
> operating systems, 

It's far from obvious that TC will have no part to play in the next
few decades of open warfare against linux from microsoft.  There are
any number of ways to extend the existing dirty tricks regarding
formats, protocols, licensing etc using the TC hardware enforcement.

> The EFF attempts to distinguish one feature of TC, remote
> attestation, as a source of problems.  This is the ability of a
> computer user to convince other systems about what software he is
> running.  The EFF is convinced that this feature will cause users to
> be compelled to use software not of their choice; harm
> interoperability and encourage lock-in; and support DRM and various
> restrictive kinds of licensing.

Yes indeed and they are quite right.  That is exactly the problem with
remote attestation.

> But when we break these down in detail, many of the problems either
> go away or are not due to attestation.

More unsubstantiated claims.  This statement is both false and not
backed up by any of your following text.

> Software choice limitation may occur if a remote system provides
> some service conditional on the software being used to access it.
> But that's not really a limitation of choice, because the user could
> always elect not to receive the offered service.

This is really strange logic: you have a choice not to use a client
because you don't have to use the service?!!?  

Of course it detracts from choice.  Absent remote attestation things
would be as they are today and users could modify existing clients,
write their own clients, or obtain third party clients for any
service.  Removing _that_ choice is the problem.  And it is a big and
significant detraction from the current open nature of the internet.
One that favors large companies such as microsoft with an interest to
stifle innovation and competition.

> The implicit assumption here seems to be that if TC did not exist,
> the service would be offered without any limitations.  

Yes it would.  It either wouldn't be offered or it would be offered
without such limitations.  These are the trade-offs we like because
they are open and offer a level playing field and user choice.

The "choices" you promote come down to the end-user not owning and
controlling their own hardware.

Freedom of choice be damned.

> Then it makes it appear that TC adds limitations which are not
> currently present.

And indeed it does add limitations as I discussed above.

> Turning to the issues of lock-in and interoperability, it is true
> that TC may allow software creators to lock their data to the
> applications and make it more difficult to create interoperable
> alternatives, thus promoting lock-in.

Yes indeeed it is true that it will create ever worse lock-in and
interoperability problems.

> The problem here with the EFF analysis is that it is not the remote
> attestation feature of TC which is the primary cause of this effect,
> but rather it is the sealed storage feature.

They are both problems.  You are right in the limited sense that
Schoen should _also_ have objected to the lock-in enabling aspects of
the sealing function.

> It is sealed storage that allows data to be encrypted such that only
> one particular application can decrypt it, and potentially makes it
> impossible to switch to a different software package, or access the data
> in an interoperable way.

That creates lock-in problems yes.  Network effects are worse
multipliers of interop problems were (one of Ross Anderson's
scenarios) microsoft uses sealing to prevent openoffice etal reading
MS word documents.

> And parenthetically, lock-in is not necessarily a bad thing, as long as
> people know about it in advance.  When you go on vacation you know that
> you will only be able to eat at restaurants in the local area.  You are
> locked-in to local eateries.  Everyone accepts this as part of the cost
> of the vacation.  

It's artificial lock-ins which are bad economics for consumers.  They
result in higher prices to prop up the profits of those creating the
lock-in.  Commoditization is good for consumers.  Lock-ins are
attempts to decommoditize by microsoft to extend their waning days as
a virtual monopoly.

> But in any case, once it happens, again the report fails to paint a
> balanced picture, by emphasizing the negative aspects of the new kinds
> of licensing that TC will enable.  It should be clear that a technology
> that allows new kinds of voluntary arrangements, without eliminating
> any old ones, cannot be entirely evil.  

But it doesn't do that.  It brings in a new era where the defacto is
controlled and owned up by microsoft and the user has no rights and no
control over their own machines.

> TC only expands the space of possibilities, it does not stop anyone
> from doing things the old way.

Here's that falacious argument again.  In theory what you say may be
true.  In practice it is utterly false and you know it.  Microsoft
will do it's worst to ensure that it does stop people doing things the
old way.  That means that the next sweep of intentionally not
backwards compatible and yet still defacto standard software from
microsoft will not be available without it.  And so your only "choice"
will be shutting yourself off from the rest of the world, or putting
up with ceding control of the platform wholly to microsoft.  Of course
given your contorted logic further up, this would seem like a fine
"choice" to you.

> If the new possibilities enabled by TC are truly so horrible for
> consumers, and if it is possible (as TC opponents implicitly assume) to
> provide these functionalities without the nightmarish limitations that the
> report is so afraid of, then some companies can still offer their goods
> under those more-favorable terms, and reap massive rewards as consumers
> triumphantly reject the horrific license terms of the TC-based software.

Wrong again.  Microsoft will ride the pain barrier between this
lock-in and the cost of switching.  It may even subsidize short term
to gain the longer term lock-in to put others out of business.

> This report, like so many others, ignores the role of consumers in making
> decisions about what technologies to use.  This is one area in which the
> EFF was unable to rise above the myopia shared by so many other analyses.

Wrong.  It's just your own microsoft centric myopia doesn't enable you
to see the obvious.  You stick legalistically and pedantically to what
is released in microsoft PR documents, but refuse to acknowledge or
even think for yourself far enough to realise the obvious conclusion
this horrendous wrong-turn for netfreedoms will reach given the long
term business plans and obvious previous tactics which will be
translated to apply and extend the effect of this until it has a
stranglehold on the world.  Again freedoms be damned.

> The final complaint about the report is that their solution doesn't
> seem to make sense.  The basic idea is to allow the user to override
> the remote attestation feature so his system can lie about his
> software configuration.  The apparent problem with this, as a number of
> commentators have pointed out, is that it undercuts the remote attestation
> feature and makes it useless.  

No it doesn't.  Hostile software can't undermine the users
configuration or software.  It just makes the machine act once again
under user control.

> It is like "fixing" the limitations of cryptographic certificates by
> allowing anyone to forge them.

No.  It's like allowing user blinding of certificates to ensure
privacy.  You allow user change of software to enable user control.  

> Doing this defeats the purpose of the feature so completely that you
> might as well not have it.  

Wrong.  See above.

> It would seem to make more sense for the
> EFF to simply call for remote attestation to be removed from the TC
> concept than to try to come up with a complicated "owner override".

Wrong.  The host security aspects still exist with owner override.

> Now, perhaps there are some subtle aspects to the EFF proposal which
> would make attestation with owner overrides more useful than a version
> of TC without attestation at all.

Ah so you do concede that despite your claim to the contrary above.

-end-





More information about the cypherpunks-legacy mailing list