[34] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

Re: GSS API...

daemon@ATHENA.MIT.EDU (Brian Behlendorf)
Tue Aug 16 20:39:07 1994

Date: Tue, 16 Aug 1994 14:25:34 -0700 (PDT)
From: Brian Behlendorf <brian@wired.com>
To: Jeff Hostetler <jeff@spyglass.com>
cc: "Roger Masse's the named" <rmasse@cnri.reston.va.us>,
        www-security@ns1.rutgers.edu, jeff@fido.spyglass.com
In-Reply-To: <9408162018.AA24565@fido.spyglass.com>

On Tue, 16 Aug 1994, Jeff Hostetler wrote:
> --Unless we can convice browser vendors to build decryption
> --into the client application AND disable CUT/COPY/SAVE/etc
> --when viewing copyrighted materials.  I don't look for this
> --to happen.
> 
> Even if we timestamp or in some other manner uniquely mark
> each paid-for copy of the document (to facilitate an after-the-fact
> trace/audit), the user could still just edit the document and
> rip it out.
> 
> I just don't see how we can get around this.

Not that this is likely to solve the problem, but a certain map maker (I
*think* it's Rand McNally but I'm not sure) has been known to do interesting
things with their maps to make sure it can tell if they've been copied. 
Things like, changing the elevation measurements by a hundred feet, creating
rivers where there aren't ones, or even creating small towns in the middle of
nowhere.  Reportedly photography clearinghouses are looking into placing
codes into their digital distribution of pictures by imperceptibly adjusting
color tones at particular places, resulting in a form of signature that 
can be uniquely assigned for every sale and difficult (using an MD5 
checksum, possible) to modify.

Short of changing the document itself in a difficult-to-change way on 
the fly, I as well do not see an easy method for preventing further 
un-paid-for reproduction.  Yet I don't think this is a problem, really.

	Brian

home help back first fref pref prev next nref lref last post