1997-04-14 - Re: SSL weakness affecting links from pa

Header Data

From: Black Unicorn <unicorn@schloss.li>
To: Tom Weinstein <tomw@netscape.com>
Message Hash: 31fb239c510a84d08588fc7d23bb790575c954b247edc0cad4107f247e3d6a81
Message ID: <Pine.SUN.3.96.970414115216.28199C-100000@polaris.mindport.net>
Reply To: <3351F2DF.7DC26A1A@netscape.com>
UTC Datetime: 1997-04-14 16:20:14 UTC
Raw Date: Mon, 14 Apr 1997 09:20:14 -0700 (PDT)

Raw message

From: Black Unicorn <unicorn@schloss.li>
Date: Mon, 14 Apr 1997 09:20:14 -0700 (PDT)
To: Tom Weinstein <tomw@netscape.com>
Subject: Re: SSL weakness affecting links from pa
In-Reply-To: <3351F2DF.7DC26A1A@netscape.com>
Message-ID: <Pine.SUN.3.96.970414115216.28199C-100000@polaris.mindport.net>
MIME-Version: 1.0
Content-Type: text/plain


On Mon, 14 Apr 1997, Tom Weinstein wrote:

> 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.
> 
> So, you think we're doing something bad.  Why don't you tell me what
> you think we should do?

Thanks for the chance to address the issue.

I think that perfectly reasonable "features" often can become "security
flaws" or "privacy lapses" when the user is not aware of the potential
danger.  In this case I think much of the flak over the referer header is
driven by the fact that no one really appreciated the danger until it was
pointed out.  This gives rise to the "My god!  What have I been giving out
all these months while accessing www.hotchicks.com?" panic.  Of course
the next step is anger.  "Why the hell does <netscape> do that?  Why
wasn't I told?"

This melds into another software annoyance of mine.  Sacrificing the needs
of the user who knows what he is doing for the novice when both can be
easily satisified.  Of course the reverse is also true.  Take, for
example, Mr. Stewart's comment:

>I basically agree with Microsoft.  It works as specified, and everyone
>should know that handling sensitive form posts via GET is a bad idea.

Well, those of us who know what we are doing should know better but (and
I'm not sure this is Mr. Weinstein's mission or concern) if you want to
educate the public you need to assume the user does not know and create
and option to streamline operation for the user who does.

Having said the above, what I would like to see is an option to surpress
the referer header explicitly like with cookies.

"You are about to forward a referer header to the page you have selected.
Forwarding the referer header to this site may reveal more about your web
browsing habits than you would prefer.  Should <netscape> surpress the
referer header?  Yes/No/Always Surpress/Never Surpress."

I might add that I would like an option on cookie supression to bypass
that annoying dialog such to never allow cookies.  It gets a bit much when
a page askes for 9 cookies in a row and the only way to prevent them is to
get beeped at repeatedly.  Again, don't confuse the novice, don't slow
down the expert.

> -- 
> You should only break rules of style if you can    | Tom Weinstein
> coherently explain what you gain by so doing.      | tomw@netscape.com

--
Forward complaints to : European Association of Envelope Manufactures
Finger for Public Key   Gutenbergstrasse 21;Postfach;CH-3001;Bern
Vote Monarchist         Switzerland







Thread