HP3000-L Archives

October 2002, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tom Emerson <[log in to unmask]>
Reply To:
Tom Emerson <[log in to unmask]>
Date:
Tue, 1 Oct 2002 17:16:09 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (74 lines)
> -----Original Message-----
> From: Wirt Atmar
>
> Although I hate to agree with Denys, I don't see anything
> overwhelmingly
> nefarious about these super-hidden files. I've tracked down
[...essentially streaming-media buffered data...]
>
> When streaming video files are delievered to you, they aren't
> synchronously
> locked to the server. Rather, a few seconds of the material
> is buffered
> (stored) on your PC, constantly running a least a few seconds
> ahead of your
> consumption of the streamed video/audio file. But no one
> wants this buffered
> material out in the open, where it can be readily copied
> without the control
> of the original authors; thus this material is put into
> folders that WE was
> purposefully designed not to readily expose to the general public.

Aye, and therein lies the rub: at "some point" the data has to be available
in a form ready to submit to the "media device" [screen/speakers] at which
point it is susceptible to "capture".  Even with the most convoluted
compression/encryption algorithms in place, eventually it has to be
decrypted for play.  Here's where one of DOS's greatest weaknesses comes
into play: everything on a PC effectively "runs as root" [to use unix/linux
terminology], so it is impossible to keep someone from creating a program
that "watches" for the decrypted data and copying it elsewhere.  [consider
for a moment if the HP3000 were a "multimedia" machine: a "user process"
cannot read the memory of another "user process", hence this sort of
"snooping" could be stopped; however, we all know that programs with SM
capability can "read" the memory of another process -- deny users access to
such a capability and you effectively deny them the ability to "snoop" the
data...]

Of course, even if DOS/windows was "fixed" to have a similar memory
access/restriction mechanism as found on the HP, there is the fact that each
"user" is in effect the system manager, so they'll simply enable the "bad SM
program" and capture away :)  [and yes, "even if they did use Linux" (which
has similar "super user" restrictions), you'll have the same problem: the
person running the computer is often the one that installed it, and
therefore "is root anyway" (or knows the password)]

> We're going to do the same thing our coming tutorial product.
> Indeed, we have
> to do the same if we are ever going to be able to recruit
> authors to generate
> copyrighted material in our format. Protecting intellectual
> property in a
> digital world, where anything can be copied perfectly at
> virtually no cost,
> is not an easy task.

What you need then is memory made from unobtanium: it has two interesting
possibilities: (1), it is infinte, and (2) it can only be written to and
read from once (hence the need for it to be infinite)  So if "some other
process" is trying to snoop the decrypted data, either the data has already
been read by the "proper" media-presentation program [so it can't be read
again] or the "snooping" program will read it, but cannot re-write it to
keep the "legit" program running properly.  Of course, the "proper"
presentation program will only read from the address given by the decryptor,
so even if the "snooping" program tried to re-write the data [elsewhere] in
the read/write-one-time memory, the presentation program will fail... [err,
does this make sense?]

In other words, this is memory that cannot be "copied" once it has been
written, nor can what has been read from it be re-written so that it doesn't
appear as if it has been read already [oww, that's making MY head hurt :) ]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2