Re: Unverifiable Transactions / Cookie draft

Rob Hartill:
> 
>On Sun, 16 Mar 1997, Koen Holtman wrote:
>> 
>> 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.

Hmmm.  The idea is that you do the measuring in the click-though CGI
script which returns the 302 to the as image.  The 302 message should
be highly uncachable: the spec says it is not for one thing.  A nice
way to make it even more uncachable for some legacy browser caches is
to make the ad gif into a clickable map: this generates an additional
semi-random URI component.

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

So in your scheme, the ad server counts 1c) transactions, and this is
what your revenue is based on?  Well in that case of course the 1c)
site would have to make 1c) highly uncachable.

My design above however has the counting on which the revenue is based
in the 1d) transaction, not the 1c) transaction, so 1c) is cachable.
Of course this requires some mutual trust between 1d) site and the
people who are paying.

[Note: I looked at your site and I could not find any use of the 302
ad serving scheme above.  I did find some use of 302 for
clickthroughs, so I'm not entirely sure we are talking about the same
thing here.  Could you point to an example of what you are using now?]

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

They can be good citizens if they measure their hits in a script which
redirects to the ads.  Of course, they will need to cache-bust the
script, but this is cheaper for the net than cache-busting the ad.

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

I do expect them to bust, but not on large images like they do now.
The design above will increase the degree of caching while people
still bust the revenue counter.

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

I have good news: unverifiable transactions may add some overhead for
these sites, but HTTP/1.1 removes a lot of overhead in the same
timeframe.  So I don't expect that our protocols will cost them extra
money on hardware.  Of course, they will be spending some money just
to keep up with the growth of the web.  

Also, if the site does more processing itself, and allows savings
(because of caching) on the ad network site, I would expect the ad
network to give them a some appropriate amount of extra money for
their trouble.

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

Again, the extra trip will make the ad image cachable, and ad images
are typically some 8Kb large.  The extra trip generates an extra
uncachable response of about 0.5 Kb, but this is tiny in comparison.

>Whichever way you look at it, it's going to slow down the content sites
>and slow down delivery times for ads.

It will speed delivery if there are proxy caches in the loop.  I agree
that for those who are not behind proxy caches, things may get
slightly slower.  But the worsening would be 8.5Kb in stead of 8Kb, so
you'd not even notice the slow-down factor.

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

As I explained above, by making their ads uncachable, in stead of a
making a tiny redirection response which redirects to their ads
uncachable, advertising sites are not as cheap as they can be *right
now*.  Unverifiable transactions may force ad sites to pay proper
attention to this issue, so they are a good thing for overall
efficiency.

>        2) it's likely that other loopholes will be found.

Oh, sure, there is always Java and ActiveX to have loopholes which
generate bad press.  But we will have closed at least this
bad-press-generating loophole.

>        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 

No, Y cannot set a cookie.  IF X redirects with a 302 to Y, the
transaction on Y is unverifiable.  It does not matter that it is a
page request: what matters is if the user had the option of reviewing
Y's URL.  See the definition of `unverifiable' in the spec.

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

Koen.

Received on Wednesday, 19 March 1997 02:05:58 UTC