Actually, what is REALLY funny about this is the history of the internet to begin with. TCP/IP was chosen because it was open source at the time. IPX was much more secure but it belonged to Novell. Everyone knew that, but security was the not the issue at the time. Now it is, so we are going to go with a different unproven, but supposedly more secure protocol? :o)

Typical....
Tracy

>>http://www.pbs.org/cringely/pulpit/pulpit20020627.html
>>
>>
>>'What bothers me the most about it is not just that we are being sold a bill of goods by the very outfit responsible for making possible most current Internet security problems. "The world is a fearful place (because we allowed it to be by introducing vulnerable designs followed by clueless security initiatives) so let us fix it for you." '
>
>Futher information is at
>http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
>
>And the following email was extracted from
>http://www.cl.cam.ac.uk/~rja14/lucky
>
>Return-path:
>Envelope-to: Ross.Anderson@cl.cam.ac.uk
>Delivery-date: Thu, 27 Jun 2002 05:15:43 +0100
>Received: from pakastelohi.cypherpunks.to ([213.130.163.34])
> by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1)
> id 17NQh5-0004ex-00
> for Ross.Anderson@cl.cam.ac.uk; Thu, 27 Jun 2002 05:15:43 +0100
>Received: from LUCKYVAIO (unknown [209.148.102.64])
> (using TLSv1 with cipher RC4-MD5 (128/128 bits))
> (No client certificate requested)
> by pakastelohi.cypherpunks.to (Postfix) with ESMTP
> id 990573668F; Thu, 27 Jun 2002 06:15:37 +0200 (CEST)
>From: "Lucky Green"
>To: ,
>Cc: "Ross Anderson"
>Subject: Two additional TCPA/Palladium plays
>Date: Wed, 26 Jun 2002 21:10:25 -0700
>Message-ID: <037901c21d90$94807d60$0100a8c0@LUCKYVAIO>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook, Build 10.0.3416
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
>
>[Minor plug: I am scheduled to give a talk on TCPA at this year's DEF
>CON security conference. I promise it will be an interesting talk.
>http://www.defcon.org ]
>
>Below are two more additional TCPA plays that I am in a position to
>mention:
>
>1) Permanently lock out competitors from your file formats.
>
>From Steven Levy's article:
>"A more interesting possibility is that Palladium could help introduce
>DRM to business and just plain people. It's a funny thing," says Bill
>Gates. "We came at this thinking about music, but then we realized that
>e-mail and documents were far more interesting domains."
>
>Here it is why it is a more interesting possibility to Microsoft for
>Palladium to help introduce DRM to business and "just plain people" than
>to solely utilize DRM to prevent copying of digital entertainment
>content:
>
>It is true that Microsoft, Intel, and other key TCPA members consider
>DRM an enabler of the PC as the hub of the future home entertainment
>network. As Ross pointed out, by adding DRM to the platform, Microsoft
>and Intel, are able to grow the market for the platform.
>
>However, this alone does little to enhance Microsoft's already sizable
>existing core business. As Bill Gates stated, Microsoft plans to wrap
>their entire set of file formats with DRM. How does this help
>Microsoft's core business? Very simple: enabling DRM for MS Word
>documents makes it illegal under the DMCA to create competing software
>that can read or otherwise process the application's file format without
>the application vendor's permission.
>
>Future maintainers of open source office suites will be faced with a
>very simple choice: don't enable the software to read Microsoft's file
>formats or go to jail. Anyone who doubts that such a thing could happen
>is encouraged to familiarize themselves with the case of Dmitry
>Skylarov, who was arrested after last year's DEF CON conference for
>creating software that permitted processing of a DRM-wrapped document
>file format.
>
>Permanently locking out competition is a feature that of course does not
>just appeal to Microsoft alone. A great many dominant application
>vendors are looking forward to locking out their competition. The beauty
>of this play is that the application vendors themselves never need to
>make that call to the FBI themselves and incur the resultant backlash
>from the public that Adobe experienced in the Skylarov case. The content
>providers or some of those utilizing the ubiquitously supported DRM
>features will eagerly make that call instead.
>
>In one fell swoop, application vendors, such as Microsoft and many
>others, create a situation in which the full force of the U.S. judicial
>system can be brought to bear on anyone attempting to compete with a
>dominant application vendor. This is one of the several ways in which
>TCPA enables stifling competition.
>
>The above is one of the near to medium objectives the TCPA helps meet.
>[The short-term core application objective is of course to ensure
>payment for any and all copies of your application out there]. Below is
>a mid to long term objective:
>
>2) Lock documents to application licensing
>
>As the Levy article mentions, Palladium will permit the creation of
>documents with a given lifetime. This feature by necessity requires a
>secure clock, not just at the desktop of the creator of the document,
>but also on the desktops of all parties that might in the future read
>such documents. Since PC's do not ship with secure clocks that the owner
>of the PC is unable to alter and since the TCPA's specs do not mandate
>such an expensive hardware solution, any implementation of limited
>lifetime documents must by necessity obtain the time elsewhere. The
>obvious source for secure time is a TPM authenticated time server that
>distributes the time over the Internet.
>
>In other words, Palladium and other TCPA-based applications will require
>at least occasional Internet access to operate.
>
>It is during such mandatory Internet access that licensing-related
>information will be pushed to the desktop. One such set of information
>would be blacklists of widely-distributed pirated copies of application
>software (you don't need TCPA for this feature if the user downloads and
>installs periodic software updates, but the user may choose to live with
>application bugs that are fixed in the update rather than see her unpaid
>software disabled).
>
>With TCPA and DRM on all documents, the application vendor's powers
>increase vastly: the application vendor can now not just invalidate
>copies of applications for failure to pay ongoing licensing fees, but
>can invalidate all documents that were ever created with the help of
>this application. Regardless how widely the documents may have been
>distributed or on who's computer the documents may reside at present.
>
>Furthermore, this feature enables world-wide remote invalidation of a
>document file for reasons other than failure to pay ongoing licensing
>fees to the application vendor. To give just one example, documents can
>be remotely invalidated pursuant to a court order, as might be given if
>the author of the document were to distribute DeCSS v3 or Scientology
>scriptures in the future DRM protected format. All that is required to
>perform such an administrative invalidation of a document is either a
>sample copy of the document from which one can obtain its globally
>unique ID, the serial number of the application that created the
>document, or the public key of the person who licensed the application.
>(Other ways to exist but are omitted in the interest of brevity).
>
>--Lucky Green

.·*´¨)
.·`TCH
(..·*

010000110101001101101000011000010111001001110000010011110111001001000010011101010111001101110100
"When the debate is lost, slander becomes the tool of the loser." - Socrates
Vita contingit, Vive cum eo. (Life Happens, Live With it.)
"Life is not measured by the number of breaths we take, but by the moments that take our breath away." -- author unknown
"De omnibus dubitandum"