Goals and assumptions

  In the remainder of this paper, our goal is to enable site A to monitor how many legitimate referrals it gives to site B, or more specifically, how many times B receives an HTTP request from a user's browser for pageB.html with a Referrer header naming some URL on site A (i.e., message 2 in Figure 1); we take this as the number of click-throughs for which A should be paid. Note that this number includes any such request received by B, regardless of how B responded to it (with pageB.html or with an error message), but it does not include requests that B did not receive, e.g., because B was down. However, because A cannot monitor exactly which messages B receives, we must settle for solutions that enable A to approximate this number. For reasons discussed in Section 1.1, it is difficult to monitor this number given the way that click-throughs presently work. Thus, our solutions modify how the click-through happens, but we allow them to do so only in a way as to impact traffic patterns, server load, and users' experiences as little as possible.

In forming our solutions, we assume that the user's browser is a frame-enabled and JavaScript-enabled off-the-shelf browser. We view the user's browser as a trusted-but-oblivious third party: we assume that it faithfully interprets the web pages (including JavaScript commands, when necessary) fed to it, but we do not assume that it has been modified in any way to support our approaches. In the JavaScript code segments included in this paper, we have allowed ourselves the full expressiveness of JavaScript 1.2, but versions for JavaScript 1.1, and in some cases JavaScript 1.0, can be formulated. The effectiveness of our JavaScript code segments has been verified using both Netscape Communicator 4.03 and Internet Explorer 4.0 over Windows 95 as the user's browser (subsequently abbreviated ``NC4'' and ``IE4'', respectively) and two Apache web servers on different hosts in different domains as sites A and B.