Re: Unverifiable Transactions / Cookie draft

On Sun, 16 Mar 1997, Koen Holtman wrote:

> >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.

I think the argument was that adding a 302 would add extra processing
effort to the content site. That's true. For many of these sites, there's
currently no overhead in putting up a URL to the ad site and letting them
handle *everything*.

> >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.

True. I only said it introduced 'problems' - not bugs. The 'problems'
will have a significant impact on click-through rates and ads served
per pageview.

> > 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.

This "future" method is what I'm using now. However, 1c is NOT cacheable
(for us) in practise; we've had to make it deliberately uncacheable because
we were getting screwed (financially) by caches that'd never inform the
ad server that it had served the same ad to dozens or hundreds of users.

I know there are plans to make proxies report this kind of info in the
future, but we're not there yet and sites that are dependant on ad revenue
cannot afford to be good net citizens w.r.t caching ads.

> End result: higher degree of proxy caching on the web.

*if* people don't deliberately cache bust to protect their revenues. I
think that's going to be a big 'if'.

> 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).

IMO, that's assuming a hell of a lot and I don't agree with the assumption
that it'll end up being cheap. I think it'll be expensive enough to
cause some casualties among small sites that rely on ad networks.

> 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.

Now you've lost me. We end up with an extra trip to the content site
and because this will be persistent, this extra trip will save us something ?
Whichever way you look at it, it's going to slow down the content sites
and slow down delivery times for ads.

> >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.

I've no intention of doing either. If someone wants to offer a service
via cookies then good luck to them. My site isn't at all reliant on
DoubleClick because we sell/deliver far more of our own ads.

What I want to contribute to this discussion are 3 points:
	1) the simple/cheap alternatives aren't half as cheap/simple as
		some might think.
	2) it's likely that other loopholes will be found.
	3) the new loopholes could have a more negative effect on web
		traffic.

> >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.

What I meant was redirecting the main request (pageview) rather than
an inline image. If X redirects to Y before displaying the page, Y can
set a cookie and redirect back to the page on X which then includes the
inline from Y. Kind of a front-door into the site... come back when you've
'registered' with the ad company. Now that might not be possible, but
it does look possible to me.


--
Rob Hartill   Internet Movie Database (Ltd)
http://us.imdb.com/Oscars/oscars_1996 -  hype free Oscars (R) info.
http://us.imdb.com/usr/sweepstake     -  Win a 56k X2 modem. Free draw.

Received on Sunday, 16 March 1997 08:41:11 UTC