RE: Unverifiable Transactions / Cookie draft

The IETF is not a social engineering organization and its purpose is not
for users to "forcefully indicate their preferences to UA vendors." I
also wasn't aware that "UA publishers have been left with a great deal
of freedom as to how they present the required information to the user."
was a bad thing. I thought this was a free country where UA vendors are
free to produce the product they want and users are free to use it if
they want.

I suppose I should thank you. At least you have publicly admitted that
you are engaged in nothing more than social engineering. You couldn't
get what you wanted through the market so now you will get it through
the standards process. I am sure all the UA vendors will come out with
ringing endorsement of the cookie standard and will fight each other to
prove just how "privacy sensitive" they are. This will be easy because
the cookie standard is, with noted exceptions, a good thing and believe
it or not David, UA vendors really do care about user privacy. I work
for one of those vendors and I know I care. But I also care about the
IETF and the critical role it has to play in the development of the
Internet. What your end run around the market has accomplished is to
convince vendors that the IETF is a dangerous place to create standards.
After all, vendors want to work with an organization where they are
partners in the standards process, not its target.

		Yaron

> -----Original Message-----
> From:	David W. Morris [SMTP:dwm@xpasc.com]
> Sent:	Tuesday, March 18, 1997 10:50 PM
> To:	Yaron Goland
> Cc:	http working group
> Subject:	RE: Unverifiable Transactions / Cookie draft
> 
> 
> 
> On Tue, 18 Mar 1997, Yaron Goland wrote:
> 
> > The average user doesn't know about cookies and frankly they don't
> want
> > to know about cookies. However browser implementers are now forced
> to
> > put UI in front of them to tell them more than they ever cared to
> know
> > about cookies. Since the user doesn't know what a cookie is, they
> are
> > going to call up to find out what the heck this cookie stuff is
> about.
> > Who pays for that call? The browser implementer. So a wire protocol
> is
> > taking away browser implementers right to control the experience
> users
> > have with the very program the browser implementer is selling.
> 
> First all, I reject your wire protocol conclusion.  HTTP is a protocol
> which allows delivery of an application between a server and a user.
> There
> has always been much more to HTTP (and its cousin HTML) than what
> flows
> over the wire. For HTTP to be useful, both the server and the user
> must
> have their expectations met. And in the case under consideration, the
> expectation deals with the user's privacy concerns.
> 
> Secondly, the standards bodies are one way users can forcefully
> indicate
> their preferences to UA vendors. The economics of UA implementation
> haven't left much room for real differentiation. When one is free
> bundled
> with the operating system and the other is free for a major segment of
> the
> population, to deliver an alternative is difficult. The UA publishers
> have
> been left with a great deal of freedom as to how they present the
> required
> information to the user. Good UI design should eliminate many of the 
> questions your average user might have ... good on screen text, help
> files, etc. For the remainder, just apply the standard for fee tech
> support and consider it a revenue opportunity. I suspect that many
> users
> will ask what the heck this cookie stuff is and just click the don't
> bother me box.  So the real issue in UI design is how to fairly
> present
> the story so that users might understand that it isn't in their best
> interest to accept all cookies.
> 
> You are beating a dead horse in my opinion when you argue that the
> HTTP
> specification shouldn't consider specifing the UI functional
> requirements
> in this area. You make a number of suggestions for clarification which
> might be reasonable for clarification of the new cookie2
> specification.
> You are more likely to get your other comments noticed by the group if
> you separate them from the not appropriate for a wire protocol
> argument.
> 
> Dave Morris

Received on Tuesday, 18 March 1997 23:25:07 UTC