From: Eric Murray <ericm@lne.com>
Date: Mon, 14 Apr 1997 09:17:53 -0700 (PDT)
To: AGRAPA@banamex.com
Subject: Re: SSL weakness affecting links from pa
In-Reply-To: <c=MX%a=_%p=BANACCI%l=CENTRALES/BARRANCA24/0001600D@mex3976bcaop1.banamex.com>
Message-ID: <199704141616.JAA12659@slack.lne.com>
MIME-Version: 1.0
Content-Type: text/plain


ARTURO GRAPA YSUNZA writes:
> 
> 
> Tom Weinstein wrote:
> 
> >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.
> 
> Stupid programmers abound even in large corporations. Bugs, patches and
> security holes are now normal everyday things. I agree with Toto.
> Companies should take more responsability in the programs they produce.

No, specification authors should take more responsibility in the specs
that they produce.  The HTTP spec's use of GET is insecure.  Specification
writers should realize that people will follow their specs, and should
be thinking of security and privacy issues as they are beig written.


> >In the eyes of some, the referer header is a privacy violation.  It
> >allows a site to see what site you visited before coming there.  In the
> >case of Navigator, we ONLY send the referer header when you click on a
> >link.  Not when you select a bookmark.  Not when you type a URL into the
> >location field.  This allows web sites to see who links to them.  I
> >think that's something that a web author is entitled to know.
> 
> NO WAY! The web author is NOT entitled to know where I came from. So if
> you go to Sears the saleperson is entitled to know you came from
> JCPenney's? If so, then I am just as much entitled to not tell him or at
> least entitled to know that there's a sign on my back that says where I
> came from. How many web users are aware of the HTTP REFERRER header? Not
> many, especially if they have not read the specs or looked at the logs
> from a web server. As an adminsitrator I AM NOT ENTITLED to that info.

Why not?  It's a useful tool to find out who has linked to you.

On the other hand, it _is_ a privacy concern, and I don't want to send it
to sites I visit.  So I included an option blocking the Referrer tag in
Cookie Jar, the cookie-blocking program I wrote.   I'd like to think that
writing it helped push Netscape into supporting better options for cookies
(see rfc2109) and into adding this option for not sending Referrer
but I'm sure there were many other louder calls for the same thing.


> Accept responsibility?  Ok, that's wishful thinking. How about not
> blaming others? How about warning your users? You didn't do it in this
> case. If you do then you can say "I told you so!"


Users need to educate themselves.  Even a fairly security and privacy
concious company like Netscape still has exectutives who feel as though
they have to answer to the bottom line and who will sacrifice consumer
privacy to get there if they feel that the advantages outweigh the risks.
Netscape has consistently led industry in realizing and fixing and admitting
security holes and privacy issues, largely due to the effort of Jeff and
the rest of their security group in educating upper management on those
issues and making them realize their importance.  However I am not willing
to bet my privacy on Netscape's good will, as it could turn at any time.

The way to real privacy is to educate oneself.  Demanding companies to
"fix it" is lame and ineffectual.  You have the technology-  fix it
yourself!  Distribute your code.  Make the companies look bad.
Educate the sheeple.  But asking companies to look out for your privacy
is a waste of time.



-- 
   Eric Murray  ericm@lne.com         Privacy though technology!
  Network security and encryption consulting.    PGP keyid:E03F65E5