Bill Stewart, ever the realist, despite the futility of rational thought in confronting today's world, wrote:

At 01:54 AM 4/11/97 -0500, ARTURO GRAPA YSUNZA wrote:

...

See http://www.Microsoft.com/security/ under "Credit Card Security Concerns and Microsoft's Response" for Microsoft's response on the SSL GET/POST weakness. ¿Any opinions?

I was highly unimpressed with Microsoft's Response: "It's Not A Security Flaw" "But Everybody Important Works Around It" "And we're fixing it in the next release" without providing much detail about what's going on. It does indicate what to look into to avoid it when writing web pages, but it doesn't say how to avoid it when entering your credit card number into a web page, or what to look for as a non-programmer user.

Bill seems to be one of the few people to realize that tips and tricks for experienced programmers does nothing at all for the common user, who has no way of discerning which of the programs and sites that they access are indeed compensating for a system which contains a plethora of basic faults. When facing a firing squad, there is little comfort in knowing that only one or two of the rifles contain real bullets. Pardon me for suggesting that the average user will realize that he need not volunteer to face the firing squad if he doesn't want to. The 10,000 people who enter their credit card number at a web page prompt won't be on the nightly news. The guy or gal whose life was ruined when they did so, will be. Does anyone care to estimate what percentage of the 10,000 who didn't get totally screwed will think twice before using their credit card on the web again? -- Toto "The Xenix Chainsaw Massacre" http://bureau42.base.org/public/xenix/xenbody.html

Tom Weinstein wrote:

Bill Stewart wrote:

...

Thanks for the pointer to MS's security site; there's a lot of good information there.

I was highly unimpressed with Microsoft's Response: "It's Not A Security Flaw" "But Everybody Important Works Around It" "And we're fixing it in the next release" without providing much detail about what's going on. It does indicate what to look into to avoid it when writing web pages, but it doesn't say how to avoid it when entering your credit card number into a web page, or what to look for as a non-programmer user.

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

That said, there is certainly some merit to the argument that HTTP's "Referer:" is a privacy violation. Therefore, we've added a preference to Communicator that allows you to turn it off. Because of the late date there will be no UI, but if you are concerned about it, you can go into your prefs.js file (preferences.js on unix) and turn it off by adding the line:

Nothing personal, but this is horseshit. I'm getting mighty tired of vendors claiming that the average user is not getting hornswaggled by the new technology because they have the option of becoming the world's foremost computer expert and disable all of the bullshit that is foisted upon them. I have yet to see an advertisement for a product that states that the users, upon giving the vendor a pile of cash, will have a stick shoved up their butt, but will also be able to remove it if they quit their job and devote the rest of their life to figure out how to disable intrusive computer mechanisms which intrude on their lives and their privacy in a multitude of ways. Let's get real, here. Corporations add capabilities to their programs that allow themselves and other 'major players' to have their way with the user. When Joe Average, or a hacker/spammer takes advantage of the same capability, then the vendors claim it is a 'bug', or that they can't be blamed for the 'bad guys' use of this built-in function. Major News Flash!!! If it is 'abuse' when I use it, then it is 'abuse' when the vendors who programmed it that way use it, as well. I am awaiting the day when corporations and government finally resolve their differences and announce 'Cookie-Key Escrow'. I don't mind vendors implementing whatever schemes they choose, I only resent their making the process obtuse and revealing what they are doing only when getting 'caught' doing things in the background that the average user might object to. Of course, I realize that I am being afforded the opportunity to protect myself from unwanted intrusions by adding a "Fuck You" line to my config.sys file, as long as I put it in front of the second device file pointer which begins with the letter 'c', unless it has more than two vowels in the line, in which case I have to put my left foot behind my right ear and lick my balls twice. The bottom line? Why do I have to perform esoteric manipulations to my system to defend myself from people I give money to in order to be able to use that system? It sounds suspiciously like the protection rackets, to me. -- Toto "The Xenix Chainsaw Massacre" http://bureau42.base.org/public/xenix/xenbody.html

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

Tom Weinstein wrote:

Toto wrote:

...

Let's get real, here. Corporations add capabilities to their programs that allow themselves and other 'major players' to have their way with the user. When Joe Average, or a hacker/spammer takes advantage of the same capability, then the vendors claim it is a 'bug', or that they can't be blamed for the 'bad guys' use of this built-in function.

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.

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.

And the Netscape default is to violate the user's privacy.

This allows web sites to see who links to them. I think that's something that a web author is entitled to know.

Without notifying the user of your software that information they may want to keep private is being given out? I don't think so. Why do you not instead require the web author to 'ask for permission' to know where the user last visited? Is it because the user is just considered a pawn of business interests?

So, you think we're doing something bad. Why don't you tell me what you think we should do?

My personal opinion is that you should inform your users of how, when and why the use of your software does, or can, affect their privacy. And you should give them an option of installing your software with all privacy features set to 'on'. Give your users the option of not allowing their privacy to be silently intruded on with no notification. The 'Cookie' situation is a good example of placing corporate interests ahead of the interests of those who use a browser. The fact that the capacity to turn off cookie acceptance was added after people found out and complained about their privacy being violated is not something for companies to be proud of, no matter how much their PR department may claim they are championing privacy by adding these 'features'. I realize that the corporatization of the InterNet provides certain benefits to users, but the fact of the matter is, the cost of those benefits is being hidden from the users. I would just like to see a browser which informs the average user in what way their information is being used and shared, and gives them a way to protect themselves against intrusion into their private lives and dissemination of their personal information. Believe it or not, there may be users who stumble upon or are suckered into going to a 'Bestiality and Child Perversion' site who may not want to spread this information around. When I find out that a program's installation process has stuck a hidden corncob up my ass, I'm not going to write them a thank-you note if they later come up with a 'feature' to allow me to remove it. Please be advised that my email reply to you in no way indicates a desire for my name to be sold to a 'Bestiality' mailing list, despite whether or not this is part of some standard 'specification' hidden in Netscape's fine print. (Cheap shot? Moi?) I use Netscape, and I like the different technologies being developed that expand user's horizons. However, I would rather be told what the cost is to have all of these 'free' capabilities, and be given the option of bearing the burden of whatever increased costs may arise by my not wanting to open my life and interests to every operator of a roadside stand along the Information Highway. -- Toto "The Xenix Chainsaw Massacre" http://bureau42.base.org/public/xenix/xenbody.html

A million monkeys operating under the pseudonym "Black Unicorn " typed:

"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."

Minor UI nit: it would be much much better if it said "You are about to send a 'referrer header' telling the next web site about the web page you are currently looking at. Should <netscape> send this 'referrer header'? [Yes/No/Always Send Referrer Headers/Never Send Referrer Headers]" Regards, Zooko Journeyman Disclaimers follow: I am not a cypherpunk. NOT speaking for DigiCash or any other person or organization. No PGP sig follows.

information. This is a security hole in the web site, not in the browser. The browser follows the HTTP specification. If you have a [. . .]

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.

GET forms aren't the only thing wrong with referer, btw. An associate of mine discovered some prioprietary Netscape information from the Referer: headers on hits to his website from Netscape employees, even. I commend Netscape for providing users with the ability to turn off referers. -- Sameer Parekh Voice: 510-986-8770 President FAX: 510-986-8777 C2Net http://www.c2.net/ sameer@c2.net