W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: cache-busting document

From: David W. Morris <dwm@xpasc.com>
Date: Tue, 10 Jun 1997 09:39:20 -0700 (PDT)
To: P.Lister@cranfield.ac.uk
Cc: Shel Kaphan <sjk@amazon.com>, Martin Hamilton <martin@mrrl.lut.ac.uk>, http-wg@cuckoo.hpl.hp.com, ircache@nlanr.net
Message-Id: <Pine.GSO.3.96.970610091918.29833A-100000@shell1.aimnet.com>


On Tue, 10 Jun 1997 P.Lister@cranfield.ac.uk wrote:

> certificate chain), then everything from the site can be cached as
> normal, though browsers will need to be tagged such documents a
> different colour to information which is "trusted but not secret". If
> I wish to send credit card details, I'm not bothered that the *form*
> isn't secret (and the bank's logo etc), but I do want to be sure that
> I can trust it to send details to the right place once I press the
> SUBMIT button. It's the *reply* - with my details in - that should be
> secret.

I agree that this is often the primary requirement for the user, but
a form which has an HTTPS: action doesn't appear secure to the user unless
the browser cue (e.g., the unbroken key) indicates that the page
containing the form is secure. Security is pretty confusing to the
average user anyway and every idea I've come up with for starting the
secure path with the submit has quickly broken when I look for
vulnerabilities.

Longer term, something like the Etrust model which would activate a 
browser panel light (like the secure key but new and different) indicating
that the server/site had passed a security audit of all aspects of their
handling of private data, that they had a credible security policy, etc.

I am at least as concerned about the handling of my credit card
information after the server has it as I am about the wire transfer being
secure. The potential payoff from hacking into a server's customer
database makes wire sniffing pale in comparison.

Part of what would be reviewed and audited would be the sites web page
interaction design. Were the appropriate transactions secure? And in any
case such audits would be non-trivial and not cheap. I would think at
least as comprehensive as an ISO-9000 certification audit. As important
to the audit as the current facts would be the policy and process.
Otherwise, a site couldn't be allowed to make any changes without a
repeated audit of every change which I think whould push this idea to the
level of impossible.

Dave Morris
Received on Tuesday, 10 June 1997 09:55:14 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:44 EDT