Security (was Re: Style Sheets for HTML)

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 31 May 1994 01:39:53 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <19973.770341082@hound.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Security (was Re: Style Sheets for HTML)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: Computer Science Dept, Indiana University
Organization: Computer Science Dept, Indiana University

In article <70DB@cernvm.cern.ch> Phillip Hallam-Baker writes:
>|>On Sun, 29 May 1994, Gavin Nicol wrote:
>|>that shouldn't affect too much how the document language should be
>|>constructed.  Pay-per-use (hooray for David Chaum's great keynote
>|>address at WWW'94!) and encryption belong at the HTTP layer (along
>|>with server-side and client-side programs), while stylesheets are an
>|>issue above HTML.
>
>OK first off re keeping the layers separate, very good point. Before we put
>security enhancements or rather enhancements for security into HTML we
>have to put them into the transport layer. Both Dave Ragget and myself
>are working on the security side as well as the HTML+ side so we are
>aware of the issues, state of play etc.
>
>The issues of authentification etc should be the subject of some RFC proposals
>in the near future. For a preview of Shen see :-
>
>http://alephinfo.cern.ch/AL2F01$DKA100/hallam/INFOGEN/SECURITY/REF/security_spec.html

Can't seem to get to this...

>There are some changes required to HTML+ for security. These include the
>use of logos and trademarks in a defined area that does not scroll. We
>also have to support writing "Top Secret" or "Confidential" in this area.
>The linking of DNs to trademarks is an issue.
>
>Whenever you get a copy of WiReD you know it is genuine because it has the
>trademark stamped on the front cover. Misuse of a trademark is a criminal
>act in many countries when the intent is counterfeiting.
>
>|>> For
>|>> example: Say Encyclopedia Britannica was online. How could they charge
>|>> people for using it?
>|>
>|>Actually, they are setting up an online service (www.eb.com?).  I
>|>think the model they are using is to sell the service to institutions
>|>(universities, etc) and use access control restricted to
>|>*.berkeley.edu, for example.  However, if any server in that domain
>|>has open proxying supported (as the CERN server does - does NCSA's?)
>|>then *anyone* can get that information, as the proxy service is open
>|>to anyone (or is it configurable?).
>
>There will be support for prohibit copy, prohibit cache etc.

I assume that when you say "prohibit" you mean "request that it not be
done"?  This brings up the whole interesting issue of whether it is
irresponsible to create something that provides the appearance of
security without actually providing it.  If publishers send
information out onto the wire, people will be able to copy it and give
it away.  If they are under the illusion that they can do anything
more than make it inconvenient to do so, well...

I think this problem pretty much goes away if you price your
information appropriately and in small chunks.  How much time would
you waste searching for a old pirated copy of the Britanica entry on
Uganda if you could get the authoritative, up-to-date entry from the
source for only $1?  

>|> I see this as analogous to the
>|>easily-forgeable sendmail problem awhile back, which was solved via
>|>the enlightened self-interest of the sendmail authors to enable
>|>complete tracing, so that unauthenticated mail could never be fully
>|>anonymous.

:-)

>The issue of support for proxying etc is being thought of but we are
>not there yet. The big question is about the level of trust you place
>in the client. In any copyright protection system you have to put some
>faith in the user and client.

Designing clients to they are trustworthy necessarily means designing
clients so they are not powerful and extensible.  There's a real
trade-off involved in how much we're willing to cripple client
software in order to provide a false sense of security to existing
publishing entities clinging to old ways.
--
<A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>