Pay-per-sale and pay-per-lead next up previous
Next: Conclusion Up: On the Security of Previous: Discussion

Pay-per-sale and pay-per-lead

 

If pay-per-click programs are going to be de-emphasized in the future, then it is worth considering the security of the programs that are likely to replace them. Presently, the foremost alternative to pay-per-click programs are programs in which target sites pay only for "high quality" referrals, i.e., for referred users who perform some substantial activity or make purchases at the target site. There are essentially two forms of such programs:

Payments in these programs are typically larger than in pay-per-click programs, since they are more valuable for the target sites.

It is virtually impossible for referrer sites to mount useful hit inflation attacks on such schemes, since simple clicks are worthless to the referrer. However, these programs are susceptible to a different form of fraud, known as hit shaving. In hit shaving, the target site fails to report that a referred user executed a lead or sale, thereby denying the user's referrer rightful payment (regardless of whether a third-party program provider is used). Current Web technology offers referrers little ability to detect such fraud (cf. [5]), short of the webmaster of a referrer site simply clicking through her own site to the target and, e.g., making a purchase to verify that her site is credited with this referral. This type of detection can be powerful: even if the target site attempts to shave just 5% of the commissions it is required to pay, this fraud is expected to be discovered after only 20 such probes by the referrer. However, this type of detection is not always feasible, for example if the target site sells rather expensive items (e.g., cars). In such cases, the referrers are presently at the mercy of target sites to faithfully report the leads and sales for which the referrers should be paid.

Future versions of browsers may provide a mechanism to enable a referrer to monitor the user's behavior at a target site to a limited extent. Specifically, at Bell Labs we have designed and implemented a new JavaScript security model in the free Mozilla source code (see [1]), and this is presently being considered for inclusion in Netscape 5.x browsers. This security model enables (among other things) a JavaScript program from one domain to interact with a page loaded from a different domain, provided that the latter page allows this. This feature can be used to enable the referrer site to monitor the user's actions at the target site with a JavaScript program. For example, this program could report to the referrer when the user registers or makes a transaction at the target site. The model further allows the target site to have fine-grained control over what information on a page is made available to the referrer; e.g., on the sales page, the target could make the total purchase amount available without revealing what books the user bought or the user's credit card information.

Even this new security architecture, however, does not provide machinery sufficient to fully address the hit shaving problem in pay-per-lead and pay-per-sale programs. This is the case for two reasons. First, the additional exposure of user activities to referrers that is enabled by this security architecture, which seems to be needed to combat hit shaving, may be an unacceptable privacy intrusion for many users. And consequently, the security architecture of [1] allows this exposure only with user consent. Thus, the web advertising industry may need to consider ways to motivate users to allow greater exposure of their web activities to referrers, in order to combat the threat of hit shaving. Second, a more common and unintentional form of hit shaving occurs when a user clicks from a referrer to a target, exits the browser, and then returns directly to the target later to explore the site or make a purchase. In this case, the referral is (perhaps unintentionally) "shaved", and foreseeable web infrastructure offers little machinery for the referrer to detect this.


next up previous
Next: Conclusion Up: On the Security of Previous: Discussion
Mike Reiter
3/9/1999