W3C home > Mailing lists > Public > www-html@w3.org > January 2004

Re: No current option to keep page from history.

From: David Woolley <david@djwhome.demon.co.uk>
Date: Thu, 29 Jan 2004 22:03:50 +0000 (GMT)
Message-Id: <200401292203.i0TM3ol01089@djwhome.demon.co.uk>
To: www-html@w3.org

> 
> 
> Would it be possible for the designers (programmers or whatever) of HTML
> tags to add an extra tag? One that prevents a page being listed in the
> history
> of a browser. <NOHISTORY> for example.

This is an HTTP issue, not an HTML one, as it applies equally to
resources in other media types.

> as helping them recover afterwards. Her clients could visit the page but
> since all pages are held in the browser's history, it makes it dangerous for

Unfortunately this really has to be considered a browser issue, and
in this context, chosing the browser to get the desired behaviour is
not an option, although there are other sorts of site where people
might well do that to gain this feature.

> them since their partner may find out. Deleting all of the history with the
> applications available can cause just as much trouble. The abusive partner

A paranoid partner might well install spyware, e.g. at the simplest,
run a local logging proxy.  It would take an exceptional level of 
technical knowledge to completely obscure tracks under such circumstances.
People might well be better off handling a quantifiable risk of 
detection.

> is often paranoid and evidence of covering up tracks may be construed as
> their partner having and affair, conspiring against them or even plotting to
> kill them. The consequences can be devastating.
> 
> All it would need is a tag <NOHISTORY> immediately after the <HTML> tag to

The precedent for this would be to use META elements.  Note I think
you meant NOHISTORY *element* after the HTML opening *tag*.  If you
had a specific element, the correct place would be with the other
metadata elements, anywhere within the HEAD element.  One could argue,
though that metadata is really attributes, rather than elements.

> This tag would benefit developers of secure pages as well as the above since
> a secure page can be accessed by someone on a public terminal but not
> re-visited by the next person accessing the terminal.

Public terminals should really behave as shared caches, and sensitive
pages that are not obviously private (authenticated) should use
cache-control: private.  If you want to be more aggressive in this
respect, you should use cache-control: nostore.  All this can be
done with existing, HTTP, standards.  A shared terminal really should
*always* flush history information, even if it doesn't flush its
cache of shared pages.  Internet cafes using standard products may
fail in these respects.
Received on Thursday, 29 January 2004 17:04:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:59 GMT