Re: Unverifiable Transactions / Cookie draft

Rob Hartill:
>
>On Sat, 15 Mar 1997, Koen Holtman wrote:
>
>> >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.
>
>It'd be more than "double" for many sites. If they're currently out
>of the loop there's no overhead. If they become part of the loop and
>have to do a '302' redirect then they have some new overhead. That's
>worse than double.

The providers are part of the loop already: they serve the
advertising-supported content, remember?  I argue that doing a 302 would not
double their total cost.

>Bringing the "smaller" site into the loop also introduces problems
>with some proxies and browser caches which will hit the content site
>to get the "302" but use a cache instead of proceeding to the advertisers
>site.

Caching of ad images is a feature, not a bug.

> There are ways around that. From experience I can assure you they
>aren't 100% satisfactory.


When we were architecting the state management spec, I thought a great deal
about effiency losses, and I concluded that the overhead would be small
enough for the provider, and *negative* for the web as a whole.

Transactions now:

1a) host: a.com  GET page
1b.1) host: a.com  GET inline image
1b.2) host: a.com  GET inline image
 ....
1c) host: doubleclick.com GET ad image

Note that 1b.* and 1c may happen in parallell.  Also note that transaction
1c is not cachable in proxies (I just tried it on doubleclick) because this
would interfere with cookie processing, while ad images are potentially some
of the most highly cachable content on the web.

Transactions in future:

1a) host: a.com  GET page
1b.1) host: a.com  GET inline image
1b.2) host: a.com  GET inline image
1d) host: a.com  GET ad image (returns 302 redirect to 1c)
 .... 
1c) host: doubleclick.com GET ad image

The new 1d is uncachable, but 1d is a very small transaction.  1c becomes
cachable in proxy caches, which is very good.

End result: higher degree of proxy caching on the web.  In fact, in my
opinion doubleclick should be using this scheme already, unverifiable
transactions or not.

End result for host a.com: this adds about the cost of 1 additional small
inline image, and some database processing (database processing is very
cheap).  And note that this additional transaction this will soon happen on
a HTTP/1.1 persistent connection.

So again, things turn out better for the web as a whole.

>For the record, my company is part of the Doubleclick network and we already
>use 302s. I dislike ad cookies myself,

Then you should try to convince doubleclick to omit ad cookies for your
company, or convince your company to switch to an ad provider which does
omit them.

> but I do accept them (temporarily
>that is - my cookie file is read-only so I get fresh ones each session).
>This is a must for me because I have to do a lot of link validating and
>content checking of other sites. I often end up with dozens of cookies
>by the time I'm done and dread to think what kind of user profile I'd
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>collect considering the diversity of site I have to check.
 ^^^^^^^

Yup, that is the basic argument when it comes to explaining why Europeans
don't want anyone to gather info on us.  It would be bad enough if all user
profiles were accurate, but some people will get wildly inaccurate profiles,
the bad reputation of which will precede them when they try to do business
with a company which has access to the profile.

>
>I don't know if this is possible, but we might end up with something
>crazy like the following as a way to set the cookie behind the user's
>back..
>
>- user visits content site 'X'.
>- X sees user hasn't got X's cookie so bounces user to ad site Y
>- ad site Y sets its cookie and redirects user back to content site X

This step is not possible: if you redirect to another server, all
transactions on that server are unverifiable, so Y cannot set a cookie.

>- content site X sets its own cookie.
>
>So the user goes on a quick (unseen perhaps) trip to set the cookies
>needed to get us back to where we are today.

>
>
>> 1) If you visit search engine X, your browser allows doubleclick
>>    to know what you are doing!
>
>That's not quite fair. Doubleclick won't know what you're doing other
>than visiting one of its network sites.

Mass media scare headlines are seldom completely fair.  We had a choice
between fixing mass media and fixing the protocol, so we fixed the protocol.

And besides, does the ad agency get detailed knowlegde of every ad I am
reading in any other medium?

>
>> 2) If you visit search engine X, your browser allows search engine X
>>    to know what you are doing!
>
>Perhaps a more scary scenario would be
>
>3) If you visit search engine X, they will monitor your activities on
>behalf of DoubleClick.

Not as scary as 1).  In 3) it is X who is doing it, and you would expect
them to give feedback about their readers to the ad agency which pays for
their content.  In 1), it is the software on your own computer that is doing
it.  People don't expect their software to be secretly working for somebody
else.

>It's not what's going to happen, but if network sites end up being
>"cookie proxies" on behalf of another company, then the suspicion might
>be there.

If I see an ad-supported site which does not do cookies, I *also* suspect
that they are giving their server logfiles to their ad agency.  But I end up
happier, because a logfile contains less profiling info.

>--
>Rob Hartill   Internet Movie Database (Ltd)
>http://us.imdb.com/                   -  Free cookies for selected users.
>http://us.imdb.com/usr/sweepstake     -  Win a 56k X2 modem. Free draw.

Koen.

Received on Sunday, 16 March 1997 06:57:20 UTC