W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

RE: Unverifiable Transactions / Cookie draft

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 18 Mar 1997 23:36:08 -0800
Message-Id: <11352BDEEB92CF119F3F00805F14F485025666D3@RED-44-MSG.dns.microsoft.com>
To: http working group <http-wg@cuckoo.hpl.hp.com>
BTW, I would like to make it clear that I speak for myself, not
Microsoft. The opinions I express are mine and mine alone. The postings
I have been putting out are strictly a reflection of my deep concern
about the damage I believe the cookie spec is doing to the IETF.

	Thanks,
		Yaron

> -----Original Message-----
> From:	Yaron Goland 
> Sent:	Tuesday, March 18, 1997 11:21 PM
> To:	'David W. Morris'
> Cc:	http working group
> Subject:	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:38:12 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:31 EDT