Re: Content Provider Problem?
David Berger (dvberger@CS.Berkeley.EDU)
Wed, 14 Sep 1994 12:34:19 -0700
Brian Behlendorf writes:
> On Wed, 14 Sep 1994, David Berger wrote:
> > It seems to me that security is a big deterrent to media companies
> > when it comes to putting their information on the Internet. I want to
> > know what efforts exist to protect the content provider.
> >
> > Basically, the problem decomposes into two areas:
> >
> > 1)Can you protect the information from being distributed.
>
> No.
>
> > 2)Can you mark the information such that if it is distributed, you can
> > track the one who distributed it.
>
> No.
>
> My opinion, and echoed by people around here: content providers are just
> going to have to deal with these realities. It's *unnatural* to the
> medium to try to do 1 and 2. For every step you can take towards trying
> to enforce this, someone can write a program to break that down, probably
> with less effort than you spent, too. That said, it is certainly
> possible to work against sites committing massive copyright fraud, but
> trying to prevent the average user from passing along some bits to
> another user just isn't going to work.
>
> > In each area one must consider audio, video, text, and images.
>
> "bits is bits"... there's no functional difference, really, other than
> some types take up a lot more space than others.
>
> > Area 1:
> >
> > If the content provider encrypts the information with a user's public
> > key and provides a viewer that decrypts the information using the
> > user's private key, then ostensibly the information will be somewhat
> > secure if there is no way to save a deciphered version of the
> > information from the viewer.
> >
> > Of course, other programs can grab the information off whatever output device
> > is being used. Image grabs are trivial to do, video grabs and audio
> > grabs are somewhat harder. A text grab would take some effort and
> > some OCR, but is possible. However, one can imagine stumbling blocks
> > being put in place that would deter some of these, e.g. ignore certain
> > X events etc.
>
> But it would be relatively easy, especially if I had source to the
> decrypting viewers, to write a "debabelizer" to convert the encrypted
> data to ordinary data. No screen grabbing or X events needed. Of
> course, this presumes that the encryption format is a standard or well
> known - if it's not, we've got more things to worry about than copyright.
>
> > Area 2:
> >
> > Well, how do you protect information if someone can grab it? Chiefly,
> > I'm looking to see if anyone has investigated schemes to sign an
> > image/video/audio with the user's key that are not perceptible and
> > can't be removed from the information.
>
> There has been talk here, I think, that one solution is to imbed into the
> data the content provider sends some sort of information about who
> received it - then, if a rogue archive of the CP's data appeared
> somewhere, you could trace it to a particular recipient and act
> accordingly. That's the way many commercial software packages work -
> "this copy licensed to *blah*" appears on the startup screen and is
> unchangeable (well, without hacking at the bit level I suppose). The
> problem is in finding embedding methods, particularly for plain text.
>
> > If anybody knows of people working on this problem, of papers that
> > exist, etc. Please give me some pointers to the info. Also, if
> > anyone knows of products that are being developed/exist in Area 1, I'd
> > be interested in this information also. (are the commercial web
> > browser people looking at this?)
>
> I hope not.
>
> Brian
Re: this above conversation. Clearly how liquid information "is" and
who owns "what" is a rather religious debate. But, let's not be
inflammatory. To find out what is reasonable in the paradigm of
Internet uber alles, we have to explore the issue in depth in *every*
direction. Only then can we reach a model which adequately
compensates the content provider for his/her efforts while not
creating inoordinate barriers to the use of said content. I think the
above is everybody's goal, but it is still too early to say what
exactly works.
David