Using JavaScript

  In this section, we describe a second way of achieving the message exchange shown in Figure 2. The main difference of this approach from that of the previous section is that the message exchange is achieved by embedding JavaScript commands in pageA.html, rather than employing HTTP redirection. It is also instructive for introducing techniques that will be useful in Section 3.

Suppose that when signing up for B's click-through payment program, A is instructed by B to place the following link to B in its page:

<a href="https://siteB.com/pageB.html">
Click here for site B.
</a>

In this approach, the webmaster of A constructs its pageA.html as follows. First, she makes a file pageAcontents.html that contains the (HTML commands to generate the) actual contents that she wants to display to the user, including the link to site B. This file looks as shown in Figure 3. The important aspect of pageAcontents.html is the onClick attribute added to the link to B. When the user clicks this link, the browser first executes the JavaScript code in the onClick attribute before retrieving pageB.html. In this case, the onClick attribute invokes a function called notify, defined in pageA.html as shown in Figure 4.

  

Figure 3: File pageAcontents.html for scheme of Section 2.2

  

Figure 4: File pageA.html for scheme of Section 2.2

The page pageA.html consists of a header containing a JavaScript function notify, and a body consisting of two frames: one named visible and displaying pageAcontents.html (the file in Figure 3), and the other named invisible and initially blank. As their names suggest, the visible frame consumes 100% of the browser window (see the <frameset> tag); the invisible frame is truly invisible to the user. When the user clicks the link to pageB.html in pageAcontents.html, this invokes the notify function of pageA.html with the URL of pageB.html. The notify function requests a URL on site A. This URL serves the same purpose as the dummy URL of Section 2.1, i.e., monitoring requests for this URL is the means by which A keeps track of the clicks through pageA.html to pageB.html. For example, here this URL is the URL of a CGI script on site A ( record.cgi), which is provided the URL of pageB.html as input (following the ?) for recording. Because JavaScript does not support general networking but does support fetching URLs, the notify function invokes record.cgi in a roundabout way, namely by fetching the output of the CGI script and ``displaying'' it to the user in the invisible frame. It does this by assigning the location property of the invisible frame to be the URL of the CGI script. When invoked, record.cgi simply records the referral to pageB.html and returns.

Using this simple trick, the click-through sequence has been transformed from that in Figure 1 to that in Figure 2. The browser invokes record.cgi on site A (message 2) before retrieving pageB.html from site B (messages 3,4). By using logs kept by record.cgi, site A can monitor an upper bound on how many referrals its pages have made to B.

The main risk to the claim that A maintains an upper bound on its referrals to B with this scheme is that the browser's connection back to A (message 2) might be preempted by the retrieval of pageB.html. This is conceivable if (i) the setup of the connection back to A is delayed, e.g., due to network congestion, and (ii) pageB.html is a page that overtakes the top-level browser window (as opposed to displaying in the visible frame only), thereby overwriting pageA.html. If this is deemed a significant risk, then pageB.html can be displayed in a separate browser window (so that pageA.html is not overwritten) by including a target attribute in the link to pageB.html in pageAcontents.html.