There was an unexpected error authorizing you. Please try again.

Mythbusting ads.txt

By Sam Tingleff

Recently there have been multiple stories in the industry press hinting that the ads.txt specification has a “loophole” or is otherwise flawed in a way that is being exploited within the mobile app programmatic ecosystem. The Forensiq report specifically, and miscommunication in the press, was flawed in representation — the activity uncovered in the report is exactly the type of misrepresentation and fraud that ads.txt was designed to solve.

There is no evidence of fraudulent activity bypassing the protections in place from a properly implemented ads.txt ecosystem.

The real story is that buyers need to buy inventory from authentic sources. ads.txt does not work as intended unless buyers take the steps to cut out fraud, including taking the time to validate requests against the contents of an ads.txt file, not just acknowledging the presence of an ads.txt file.

While in many integrations it may be possible for a mobile app to (attempt to) advertise itself via Real-Time Bidding as a high-value web publisher, a properly implemented ads.txt buyer will be protected. In this scenario, mobile app inventory is broadcast within an OpenRTB bid request as either in-app or “web” (display) traffic, while it fraudulently claims to have the source domain of a high-value publisher. In the Forensiq report, the misrepresented traffic is reported to have passed through the same exchange as legitimate traffic for the high value publisher.

The fraudster attempts to monetize traffic for a sketchy flashlight app at the higher rates accessible to a top-tier publisher (let’s say “premium.com”).

However, a DSP that properly implements ads.txt will have only two possible outcomes in this scenario:

  1. Ignore the domain data entirely and target the traffic as in-app with the app properly identified by bundle (let’s say “com.sketchyapps.flashlight”). This may result in low-value bids, but will not result in “spillover” bids that would properly only target legitimate premium.com traffic.
  2. Target as web inventory and validate the request against the ads.txt file found at http://www.premium.com/ads.txt, in which case the seller ID provided in the bid request within the calling exchange will not be found. No bids will be returned at all, and no spend will be wasted on misrepresented inventory.

If the seller ID provided in the bid request is found in the ads.txt file at example.com/ads.txt, the organization behind premium.com has either been duped into adding it or is complicit in the fraud. The Forensiq report does not claim to know whether or not the seller IDs match, and does not claim to know whether or not the purchasing DSP(s) have implemented ads.txt in any way.

Known Opportunities

It is fair to point out that there are three current known shortcomings with ads.txt.

  1. Adoption: Not every DSP (or exchange) has fully adopted and insulated themselves against this attack on misrepresented web inventory.
  2. Mobile app support: The specification for mobile app support is still in a public comment period and adoption is likely minimal. It is a well known possibility for a low-value app (“com.sketchyapps.flashlight”) to identify itself (though only with the support of a complicit exchange or other intermediary) as a higher value app. Note that this is very different from an app identifying itself as a high-value web site, which is the claim here and is already protected by the current specification.
  3. Badly behaved exchanges or intermediaries: It remains possible for an intermediary that acts as a legitimate source of inventory for a high-value site to blend legitimate traffic from that site with illegitimate traffic masquerading as legitimate. In this attack, the exchange sends requests to buyers that include both true human traffic and laundered traffic — both sets with the same domain and seller ID values — and then falsifies their stats and pays the publisher only for the legitimate traffic (pocketing the rest). This is a known limitation of the ads.txt specification and is intended to be solved with ads.cert coming alongside OpenRTB 3.0.

Subscribe to the ads.txt aggregator tool to access structured ads.txt data, and start targeting ads.txt inventory. Learn more about ads.txt aggregator here.


ABOUT THE AUTHOR

Sam Tingleff, Chief Technology Office, IAB Tech Lab