[dgc.chat] Fwd: [NEC] #2.12: The RIAA Succeeds Where the CypherPunks Failed

Steve Schear s.schear at comcast.net
Thu Dec 18 15:18:25 PST 2003


At 09:24 PM 12/17/2003, Patrick Chkoreff wrote:
>>The really interesting aspect of this is what it portends for the 
>>future.  If, as Clay suggests, the current situation is like Prohibition 
>>from citizen perspective can we expect a similar repeal of government 
>>surveillance?  If not, what will happen as large numbers of citizens 
>>adopt P2P systems that not only flaunt copyright law but communications 
>>more dear to those in power?
>
>Right, on the one hand it's cool that hordes of otherwise ordinary 
>computer users can become interested in "darknets," but on the other hand 
>it's a bit scary that the sheer scale of it is orders of magnitude beyond 
>getting a whiskey in a speakeasy.  This could either thoroughly discourage 
>the government or motivate them to do really draconian things like 
>requiring computers and chips to meet a specific government specification 
>which severely limits how they function.  They're working on it.

True, but if the masses understand what s at stake for them they will 
reject all such solutions where it counts: at the sales counter.  The 
following is from a posting by John Gilmore, early employee of Sun 
Microsystems, founder of the EFF and founding cypherpunk extraoridair.  I 
usually don't forward so much content from another list, in this case the 
cryptography list, but John's rants are usually quite coherent and 
incisive.  This one is no exception.

--begin forward
At 01:53 PM 12/16/2003, John Gilmore wrote:

TCPA is being built specifically at the behest of Hollywood.  It is
built around protecting "content" from "subscribers" for the benefit
of a "service provider".  I know this because I read, and kept, all
the early public design documents, such as the white paper

   http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf

(This is no longer available from the web site, but I have a copy.)
It says, on page 7-8:

   The following usage scenarios briefly illustrate the benefits of TCPA
   compliance.

   Scenario I: Remote Attestation

   TCPA remote attestation allows an application (the "challenger") to
   trust a remote platform. This trust is built by obtaining integrity
   metrics for the remote platform, securely storing these metrics and
   then ensuring that the reporting of the metrics is secure.

   For example, before making content available to a subscriber, it is
   likely that a service provider will need to know that the remote
   platform is trustworthy. The service provider's platform (the
   "challenger") queries the remote platform. During system boot, the
   challenged platform creates a cryptographic hash of the system BIOS,
   using an algorithm to create a statistically unique identifier for the
   platform. The integrity metrics are then stored.

   When it receives the query from the challenger, the remote platform
   responds by digitally signing and then sending the integrity
   metrics. The digital signature prevents tampering and allows the
   challenger to verify the signature. If the signature is verified, the
   challenger can then determine whether the identity metrics are
   trustworthy. If so, the challenger, in this case the service provider,
   can then deliver the content. It is important to note that the TCPA
   process does not make judgments regarding the integrity metrics. It
   merely reports the metrics and lets the challenger make the final
   decision regarding the trustworthiness of the remote platform.

They eventually censored out all the sample application scenarios like
DRM'd online music, and ramped up the level of jargon significantly,
so that nobody reading it can tell what it's for any more.  Now all
the documents available at that site go on for pages and pages saying
things like "FIA_UAU.1 Timing of authentication. Hierarchical to: No
other components. FIA_UAU.1.1 The TSF shall allow access to data and
keys where entity owner has given the 'world' access based on the
value of TCPA_AUTH_DATA_USAGE; access to the following commands:
TPM_SelfTestFull, TPM_ContinueSelfTest, TPM_GetTestResult,
TPM_PcrRead, TPM_DirRead, and TPM_EvictKey on behalf of the user to be
performed before the user is authenticated."

But the historical record is clear that DRM was "Usage Scenario #1"
for TCPA.

Now, back to Hollywood.  If you have not read "This Business of Music"
(a thick book on how musicians can arm themselves with knowledge to
get slightly less screwed by the record industry -- including sample
contracts and explanations of the impact and history of each
provision), you won't know the long history of why Hollywood can be
trusted only to cheat everyone they deal with.

A music-industry contract equivalent to charging for 30% more seconds
than you deliver, is the provision for "breakage".  No artist gets
paid for more than 90% of the albums that the record company sells,
because in the days of shellac records, about 10% of them would break
in shipping.  That problem largely went away with vinyl records, and
went even further away with CDs.  Today's actual breakage is way under
1%.  But record companies won't sign a contract that pays the artist
for more than 90% of the albums shipped on CD.  That 10% underpayment
of musicians goes straight back to the record company's profits.

Their DRM software will cheat users the same way -- or a different
way -- or a hundred different ways.  And TCPA will make it un-auditable
by us.

--end forward

steve





More information about the cypherpunks-legacy mailing list