Check out the new USENIX Web site. next up previous
Next: Click-through nonrepudiation Up: Cooperative approaches Previous: Cooperative approaches

Click-through acknowledgements

  In the first approach that we propose, site B effectively ``acknowledges'' each referral from A as the click-through happens. B could send an acknowledgement to A directly, i.e., by sending it in a message to A, but this requires B to incur more costs (e.g., connection setups) than is necessary. Rather, here we review a simple way in which B can piggyback the acknowledgement on its reply to the user, so that the user's browser will forward the acknowledgement to A.

Transferring an acknowledgement from B to A via the user's browser can be achieved easily with the addition of a CGI script to site B and some modifications to pageB.html. To begin with, B sets up a CGI script that serves B's web pages (possibly only for referrals from click-through program participants). Let's call this script siteB.com/cgi-bin/serve.cgi. This CGI script accepts as input the name of a page to produce (e.g., pageB.html) and emits a version of pageB.html that is slightly different for each referred request. Specifically, if B receives a request for pageB.html referred by A, then the version of pageB.html served by serve.cgi requests a dummy URL on site A when it loads. Each retrieval of this dummy URL is an implicit ``acknowledgement'' from B.

A more explicit acknowledgement can be achieved if the dummy URL on site A is a CGI script that pageB.html can invoke with B's site name and the time of the referral. For example, pageB.html emitted from serve.cgi might look as shown in Figure 8. Notice that the visible contents of the page, pageBcontents.html, are served within a frameset with one visible frame and one invisible frame (analogous to how A served pageA.html in Sections 2.2 and 3). As the frameset loads, the browser invokes A's record.cgi with the arguments provided by B. Again, the trick of invoking record.cgi by writing its output to an invisible frame is used, but this time it is done by pageB.html (vs. pageA.html). Alternatively, record.cgi could be invoked from an <img> tag, for example. The record.cgi CGI script on site A, upon being invoked, can verify that the arguments properly acknowledge A's referral.


  
Figure 8: File pageB.html in scheme of Section 4.1
\begin{figure*}
\rule{\textwidth}{.5mm}
\begin{verbatim}
<html\gt
<!-- pageB.htm...
 ...8''\gt
</frameset\gt
</html\gt\end{verbatim}\rule{\textwidth}{.5mm}\end{figure*}

Because B could serve a pageB.html that does not invoke A's record.cgi, it is advisable for A to construct pageA.html as in Section 2, i.e., so that A is informed whenever the user clicks on the link to pageB.html. This will alert A if B routinely serves a pageB.html that does not invoke the appropriate callback to A's record.cgi. A could further employ the mechanism of Section 3, providing A with the full detection capabilities offered by both approaches. In this light, the technique of this section can be viewed as a way for B to help A improve its click-through monitoring over what A can achieve without B's help using the schemes of Section 2 and Section 3. In particular, B's acknowledgement may reach A even if the notification from the scheme of Section 3 does not (e.g., because the user prematurely closes the window containing pageA.html). If A couples the detection techniques of Sections 2 and 3 with random inspections of pageB.html as served by B on a referral, B stands a high probability of being caught if it fails to acknowledge A a significant portion of the time.


next up previous
Next: Click-through nonrepudiation Up: Cooperative approaches Previous: Cooperative approaches
Mike Reiter
7/21/1998