``Associates programs'' are rapidly gaining popularity with e-commerce sites, such as amazon.com. In their associates program, amazon.com pays each participating site (like associate.com) a small percentage of a sale that results from a person's following a link from associate.com to amazon.com, i.e., by a person who was referred by associate.com. Often, the associates program is realized by a third-party network, such as linkexchange.com. Currently, both associate.com and linkexchange.com simply have to trust amazon.com to provide at the end of each month a statement that accurately reflects the sales; the business relationship is clearly stacked in favor of amazon.com -- since linkexchange.com and amazon.com are different domains, the name spaces on their respective pages are inaccessible to each other. The same applies for associate.com and amazon.com. At best the associate could know that the user clicked on their link leading them to amazon.com by appropriately instrumenting their Web page, and the third-party network could know that this happened if referrals were redirected through it. However, there is no way for either of them to verify that the user engaged in a purchase. While this may not a problem with a well-known site such as amazon.com, better accountability would boost these programs when other stores (new-vendor.com) are involved.
While using ACLs would circumvent the problem of lack of access, new-vendor.com may not be comfortable simply setting
document.ACL = "www.associate.com";on all of its relevant check-out pages, as that could potentially reveal confidential client data (e.g., credit-card number, etc.). However, new-vendor.com might be willing to reveal some of the non-confidential customer data, such as the fact that the referred client did indeed purchase a book and the amount paid. In our model, new-vendor.com would simply add the following code on the check-out page:
<SCRIPT LANGUAGE="Javascript"> document.ACL = "www.associate.com"; setPrivate(CreditCardForm, "elements"); .... </SCRIPT>The above code allows access by scripts from www.associate.com to all the elements on the page except the form with the name ``CreditCardForm''. Assuming that all the client's confidential data is in this HTML form, it is now protected. We note that the statement setPrivate(document.forms[0], "elements"); is equivalent to the above, if ``CreditCardForm'' is the first form on the HTML page. But we caution that this version is less safe. If during page evolution, a new form is inserted in front of ``CreditCardForm'', the new form will be protected while ``CreditCardForm'' is all of a sudden accessible again to www.associates.com. Therefore we strongly recommend the use of names in setPrivate.
Now, when associate refers a potential client to new-vendor, its page can stay resident on the user's desktop in its own window or frame; if the client ever reaches the check-out page at new-vendor, associate will be able to read the relevant data used to verify new-vendor's end-of-month statements. Note that new-vendor.com can generate the necessary JavaScript automatically via server-side logic based on referrer information. The ability to selectively expose information realizes a better balance in the business relationship between a store and its associates. Furthermore, as soon as the user leaves new-store.com's Web site, the associate no longer has access to any information about the user.
A similar scenario exists for sites like shop.com that serve as centralized resources providing information about online stores. shop.com's customers (online vendors) provide it with enough information to organize stores into hierarchies, provide searchable interfaces, etc. A user browsing shop.com's Web site eventually clicks on a link on a page from shop.com and is sent to store.com's Web site, which is displayed as a frame on shop.com's page. As in the earlier example, shop.com only knows that the user clicked through to store.com, and is unaware of any activity that subsequently transpires.
The new security model allows shop.com's customers (store owners) to put shop.com on the ACL of pages they serve. store.com appropriately protects the information that it considers sensitive (e.g., the user's credit card number) by marking it private. shop.com thus has access to the information that it needs for pay-per-click, pay-per-lead and pay-per-sale type scenarios.