Re: SSL weakness affecting links from pa

[Gary Howland <gary@systemics.com>]

> This particular feature (the HTTP referer header) has nothing to do with
> corporations "having their way" with users.  It was created so that web
> authors could put "back" buttons on their pages.  The security problem
> arises when stupid CGI authors use GET forms to transfer sensitive
> information.  This is a security hole in the web site, not in the
> browser.  The browser follows the HTTP specification.  If you have a
> problem with that, contact the author of that specification.  Or, better
> yet, contact the web site (as far as I know, there are none) that has
> this security hole.
> 
> So, you think we're doing something bad.  Why don't you tell me what
> you think we should do?

A couple of points.  Firstly, I don't see a need for the referer header to 
"traverse" different domains.  For example, if I have a local page called 
"dorks.html", with a link pointing to, say, David Sternlights home page,
then he can deduce my opinion of him by looking at the referrer field.
This puts an unnecessary burden on my local bookmark web pages - I can no 
longer give the pages reasonable names (such as "dorks.html").

Secondly, a back button should not be implemented using referer headers.  If I 
have a back button on my page, I expect it to do what the Netscape back button 
does.  However, this is not what happens - back buttons built into web pages 
create a long chain of "forward" links. (I'm probably not explaining myself 
too well here).  What is really required is a special type of link that does 
exactly what the netscape back button does (and it would also be nice if I 
could put forward links in my pages too).

Perhaps the latter objection is do-able in Javascript - it's been some time 
since I tried.


Gary