Security Re: Caching Servers Considered Harmful

Tue, 23 Aug 1994 12:05:54 +0200

On the caching servers question:

1) A vendor may serve information that has limited validity
2) A contract with a vendor may prohibit caching.

These issues have been considered in Shen :

Issue (1) is a non issue. A vendor can and should put an expiry date on any
time limited information. Often however data is not time limited. This is
more true of commercially published information than non-commercial data. A
new edition of WiReD implies a new URL.

Issue (2) is harder. There is of course nothing that can be done to stop a
`bad guy' from copying data delivered to an arbitrary, uncertificated browser.
The vendor cannot know what lies at the other end of the line. Thus at root
we have an honour system backed up by enforcement proceedures (police action).

The Shen proposal includes a tag Prohibit: Which may be used to forbit the
caching, copying or whatever of a document. This is orthogonal to any other
protection provided (eg encryption). As well as the cache problem there is
also the printing/saving problem. Why bother to complain about the cache
if a user can always save the page? Disabling of such facilities and of
Windows cut'n paste should be mandated by a Prohibit: Copy tag. Printing
may be considered orthogonal, I may allow a user to print a single copy of
a document but not wish it to be saved on disk.

Outside the sales environment there are occasions where other security
concerns may require the distribution of a document to be traced. Where
classified information is dealt with there should be a security trail
to make identification of all persons with access to a document possible.

Security does not come from technology. It comes from robust systems of trust
which must encompass human factors. Any security system is only as strong as its
weakest link.

On the issue of keeping the specs in sync with the code. We have an idea of how
to fix it. We have a tool that generates code from a specification. Retargetting
it at the HTTP specs should enable us to produce documentation that is in
lockstep with the code. This is taking me a little time though...

Phillip M. Hallam-Baker

Not Speaking for anyone else.