1996-12-20 - Re: Executing Encrypted Code

Header Data

From: ph@netcom.com (Peter Hendrickson)
To: “Timothy C. May” <cypherpunks@toad.com
Message Hash: b54f39dc6f9690d27c0d98fd36022f0c2b645cb996fab1dab95c110ecd96d197
Message ID: <v02140b00aedfceb8bb0f@[192.0.2.1]>
Reply To: N/A
UTC Datetime: 1996-12-20 04:49:04 UTC
Raw Date: Thu, 19 Dec 1996 20:49:04 -0800 (PST)

Raw message

From: ph@netcom.com (Peter Hendrickson)
Date: Thu, 19 Dec 1996 20:49:04 -0800 (PST)
To: "Timothy C. May" <cypherpunks@toad.com
Subject: Re: Executing Encrypted Code
Message-ID: <v02140b00aedfceb8bb0f@[192.0.2.1]>
MIME-Version: 1.0
Content-Type: text/plain


At 8:31 PM 12/19/1996, Timothy C. May wrote:
>At 7:34 PM -0800 12/19/96, Peter Hendrickson wrote:
>> You could also timestamp the software so that it only runs for a given
>> length of time.  This will encourage people to upgrade regularly.  ;-)

> Or to reset their clocks. Which is what many of us do when software is
> about to "expire."

You are right that this only works in instances where the customer just
needs a little prodding to get the upgrade and not in instances where
the customer might put up with significant inconvenience to avoid it.

However, why not use "beacons"?  The clock could have a built-in timer
that needs to be reset once a month from an authenticated source.  This
assumes the presence of net connectivity, but that's not a terrible
assumption.

Peter Hendrickson
ph@netcom.com







Thread