- From: Koen Holtman <koen@win.tue.nl>
- Date: Sat, 15 Mar 1997 19:28:23 +0100 (MET)
- 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 UTC