Combating Click Fraud via
Premium Clicks
Ari Juels*
RSA Laboratories, RSA / EMC Corp.
www.rsalabs.com
Joint work with Sid Stamm and Markus Jakobsson
RavenWhite Inc.
www.ravenwhite.com
*Research performed at RavenWhite Inc.
© 2007 RSA Laboratories
Click Fraud:
New Face on Old Scam
Click Fraud:
New Face on Old Scam
You’ll be paid
when they’re
all gone…
Advertiser
Publisher
Advertiser
Publisher
Other forms of fraud
• Publisher might have friends / colluders take
handbills, not potential customers
• Competitor might take handbills from honest
Publisher
• How is handbill problem solved? (I’ve no clue.)
An approach to think about: What if the
Advertiser requires the Publisher to get
business cards to validate people
receiving handbills?
Click Fraud
• Not problem fundamentally engendered by
new technology!
– Automation aggravates it
• Problem of limited advertiser information
about publisher behavior
• We’ll focus here on case of syndication…
Advertiser
Syndicator
Publisher
J.com
S.com
P.com
Welcome
To
P.com!
Click!
User (Alice)
Advertiser
Syndicator
Publisher
J.com
S.com
P.com
Welcome
To
P.com!
User (Alice)
Advertiser
Syndicator
Publisher
J.com
S.com
P.com
Click!
$$$
$$
User (Alice)
Syndicator
Publisher
S.com
P.com
Click!
User (Alice)
Syndicator
Publisher
S.com
P.com
Click!
$$
Welcome
To
P.com!
User (Alice)
Click!
Syndicator
Publisher
S.com
P.com
Click!
$$
Click!
User (Alice)
How to eliminate bad clicks?
• Industry practice not public
–
–
–
–
Interesting tension in economic inventives
Tuzhilin report sheds some light
Filtering is a mainstay
E.g., looking at suspicious patterns of click origination from a
given user IP address
– Subtle definitional problems, e.g., “doubleclicks”
– Third-party auditing is common
• Talk about changing business model from “pay-per-click”
to “pay-per-conversion”
– New can of worms!
• A different approach: Don’t aim to filter bad clicks, but
aim to embrace good ones!
Token Approach
Syndicator
Publisher
S.com
P.com
Click!
Click!
User (Alice)
Token Approach
Token might be used to identify browser
uniquely—or to label bad browser
• Double-click would be detectable
• But this doesn’t work!
– Attacker can delete token—we need to
support browsers without tokens
– Doesn’t detect bots
Token Approach
Syndicator
Publisher
S.com
P.com
Click!
Attestor
Click!
A.com
$$
some transaction
of value
User (Alice)
Token Approach
Token might attest to commercial transaction
performed by Alice
– E.g., “Alice has recently bought $50 of goods”
– Rare or one-time event
– Like business-card idea:
• Raises barrier for click production
• Signals honest user
– Might carry additional info, e.g., IP address
– Digitally signed / MACed for unforgeability
• But this still doesn’t quite work:
– What about clicks from users without tokens?
– No good technical remedy…
Token Approach
Let’s change the business model…
• Token attests to demonstration of special
user “value”
• For users without tokens, we stick with
current techniques
• We designate as “premium clicks” those
clicks that have accompanying tokens
– Syndicator charges / pays more
– Allows for gradual rollout
First Challenge:
Passing tokens across domains
• One possibility: Cookies
– Third-party cookies
– First-party cookies (+ Web
bugs)
– Often blocked or poorly
supported on mobiles
– Privacy problem: Syndicator
tracks User visits to Attestors
(admittedly, not uncommon)
• Another possibility: Cache
cookies
–
–
–
–
JJJ [Oakland ’06]
More broadly available
Better privacy: limit tracking
Subject to cache purging
Syndicator
Publisher
Click!
Click!
Attestor
$$
User (Alice)
Second Challenge:
Privacy
• Can peg user as
“premium” / “not premium”
• Detailed profiling also possible
Syndicator
– E.g., tax-preparation service
(secretly) puts annual income
in token
Publisher
Click!
1. How to eliminate secret
tracking / profiling?
– Tokens are client-readable
– Tokens based on IP address,
time, largely transparent
values
– What about MACs?
– Periodically refresh and
disclose keys for MACing
tokens
2. How to ensure that keys don’t
reveal Attestors, but can still be
securely distributed / revoked?
Click!
Attestor
$$
User (Alice)
Our implementation
• Advertiser, Syndicator, Attestor, Publisher
at different web sites, IP addresses
• No real difference in user experience
• A few engineering challenges surfaced:
– Need to couple token with Publisher identity:
Referer field (Challenge: consistently
misspelling “referer”)
– Freshness of tokens: Must maintain list of
recently received tokens, tune expiration
window
Limitations of Premium Clicks
• Far from perfect…
– Malware-driven clicks
– Publisher scripting clicks
– Token-harvesting attacks
– Fraudulent Attestor
• But better fraud management than filtering
– Tokens provide stronger visibility,
cryptographic footing
• And more refined picture of traffic quality
Conclusions
• Shift from filtering bad clicks to embracing good ones
– Reframes click-fraud problem: anonymous filtering  authentication
– Changes business model, but allows gradual rollout, and higher-value
services
• Techniques also applicable to other content forms, e.g., banners
• Follow-up problems:
– What attestations are useful?
• NYT subscription?
• Broad social network?
• Registered mobile-phone address (as for GMail)?
– Special-purpose client-side software
– Extension to new advertising problems, e.g., traffic measurement
– How much does privacy matter?