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

Re: Unverifiable Transactions / Cookie draft

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 15 Mar 1997 19:28:23 +0100 (MET)
Message-Id: <199703151828.TAA02622@wsooti08.win.tue.nl>
To: Yaron Goland <yarong@microsoft.com>
Cc: dmerriman@doubleclick.net, http-wg@cuckoo.hpl.hp.com
Yaron Goland:
>
>I would also point out that besides denying smaller sites revenue,

I think it is unfair to say that the third-party advertising server
model will die if the third party server cannot use cookies.  Without
cookies, the third-party server can still measure enough things (like
hit counts) to be in a position to generate revenue for small sites.

>preventing "unverifiable transactions" only puts a very small bump in
>the road of collecting user data. What companies like doubleclick will
>end up doing is providing CGI scripts to site providers that will
>automatically thunk calls through to the doubleclick.com site.

I agree with the smallness of the bump, and in fact I would encourage
companies like doubleclick to provide cookie CGI scripts (or apache
modules) to smaller site providers to make up for the loss of their
own ability to use cookies in unverifiable transactions.

Now, I will personally not bother visiting sites which use cookie
technology just to do ad targeting (and when I do I will gladly turn
of cookies) but this personal preference can stay out of this
discussion.  I recognise that many users will gladly visit sites which
offer free content supported by cookie-targeted ads, and I would not
want the IETF to block this business model.

>Of course
>smaller providers will now have to absorb what amounts to double the
>cost per transaction due to their servers have to act as a middle man
>for advertising.

The cost would not be doubled: the image could still come from
doubleclick by means of 302 redirection.

>User Privacy - 0
>Small Web Sites - 0
>
>Exactly who wins here?

The web community as a whole will win, including the small sites: read
on to see why.

The key words in the cookie spec are "privacy expectations of the
user".  The spec does not really claim to raise the level of privacy
on the web, it claims to remove some behaviour which is "contrary to
the privacy expectations of the user".

If you read the popular or digital press (the state management
subgroup sure did, mass media psychology was a major design
consideration), you'll find that the average user does *not* expect
his/her browser to interact with sites in any other domain than the
one mentioned in the browser's Location bar.  Yet, this is what
happens in unverifiable transactions, and users (press people) are
definitely disturbed that this is happening.  

Compare these two headlines:

1) If you visit search engine X, your browser allows doubleclick
   to know what you are doing!

2) If you visit search engine X, your browser allows search engine X
   to know what you are doing!

You'd have to agree that 1) is much more disturbing to the general
public, which never heard of doubleclick though they have been using
search engine X for some time.  Of course, 1) and 2) are technically
equivalent for us computer geeks because we know that search engine X
is probably running some software supplied by doubleclick, but to the
general public, 1) and 2) are very different.

Headline 1) is a member of the `your own software is secretly
violating your privacy' type of story (I'm sure you can remember at
least one other instantiation, even though the registration software
in question *did* in fact ask the user first, contrary to some reports
in the press), while 2) is a member of the much more mundane
`everybody is keeping records on you, and may give them to their ad
agency' type of story.

Users don't expect their web browsers to do 1), and this is why the
default setting in the spec is to disable cookies in unverifiable
transactions.  It would be a major design flaw if we would enable such
cookies the default.  This would put browser vendors implementing the
spec in the dangerous position of being subject to bad publicity
generated by type 1) stories.

Also, type 1) stories are not just damaging to a single browser
vendor, they ultimately undermine the general trust in the web as a
whole.  If there are lots of `your web browser is secretly violating
your privacy' stories, people will be less willing to type their
credit card number into their web browser.

So while I agree that the state management spec puts a small dent in
the business model of some third party web advertisers, I think that
it will be beneficial to the viability of web business as a whole.  In
the long term, this spec will be good for everybody, including small
sites.  (OK, a rise in web commerce will not be good for your
neighbourhood bookstore, but it will be good for almost everybody *on
the web*.)

I can have some sympathy for the third party web advertisers, and the
web sites dependent on them, who have used the unverifiable
transaction loophole up till now, but I don't have too much sympathy.
By exploiting this loophole to get higher per-ad revenues, these
people have put the web as a whole, and browser vendors in particular,
at a high risk of getting bad press.  Netscape has already had some
bad press about this.

In the end, I think that the provisions in the spec promote the
greater common good.  And I do not mind that it will cause a bit of
discomfort for some people who have not been all that considerate
themselves anyway.

Finally a process issue: I don't think that the unverifiable
transaction default in RFC 2109 is still open to revision by this WG.
It will of course be revised if all browser vendors implement another
default.

>               Yaron

Koen.
Received on Saturday, 15 March 1997 10:30:24 EST

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