Domain Spoofing Be Gone: Ads.Txt Will Filter Out Imposter Sites 

Programmatic buyers on the open exchange who think they’re purchasing inventory from ESPN or The New York Times often end up buying from imposter sites instead. At times, the amount of misrepresented inventory in the marketplace can dwarf the legitimate inventory sold by brand-name publishers.

The practice, domain spoofing, will become much harder to carry out thanks to a tech tool developed by the IAB Tech Lab called ads.txt. After a 30-day public comment period ending June 19, buyers will be able to use ads.txt data to filter out unauthorized sellers of a publisher’s inventory.

“This is a very elegant, simple solution,” said Alanna Gombert, GM of IAB Tech Lab.

Publishers put a text file on their site listing all the exchanges they work with. Buyers send web crawlers to scour publishers’ sites and collect the lists. DSPs can then choose to filter inventory so buyers only go through those listed exchanges.

“We can make sure the spend intended for that publisher actually goes to that publisher,” said Scott Spencer, Google’s global director of product management for sustainable ads. Google participated in developing the ads.txt initiative.

Ads.txt would filter out impressions pretending to be from a premium publisher, as well as any unauthorized reselling of a publisher’s inventory.

The project has been in the works since the end of 2016, spurred by increased marketer and industry awareness of fraud and new threats like Methbot, which spoofed 6,111 premium domains and 250,267 distinct URLs.

“Virtually every premium publisher had been spoofed by that botnet,” said Mike Zaneis, president and CEO of the Trustworthy Accountability Group “That’s a scary proposition for any premium publisher.”

Buyers who use whitelists, such as JPMorgan Chase, can’t tell if some sites on their lists are masquerading as a trusted publisher. Ads.txt will close this gap.

“It can’t be that there are 300 different paths to purchasing New York Times inventory. It can’t be unlimited,” Zaneis said. “A lot of that traffic must be misrepresented.”

The IAB Tech Lab could not quantify how much inventory is misrepresented.

Google said that because fraud levels fluctuate, calculating the impact of domain spoofing can be difficult.

“No one knows for sure exactly how much invalid traffic there is,” Spencer said. “It ebbs and flows over time.”

As buyers adopt ads.txt, it would be logical to see ads increase their impact. And the promise of a more trusted marketplace could woo back buyers who have recently pulled spend over concerns about fraud and brand safety.

“If you weed out fraud from the equation, performance will hopefully go up because you are buying real inventory,” Gombert said. “The holy grail now is to make sure you are buying a real user and a real site.”

Sellers could see CPMs rise as supply goes down. And a clearly labeled marketplace would allow buyers to evaluate publishers more clearly. Because buying misrepresented inventory is so common, many publishers constantly field questions from buyers with misperceptions of the publisher based on their evaluation of faked inventory.

But ads.txt doesn’t cover all types of inventory reselling and misrepresentation. Ads.txt doesn’t specify if a vendor is authorized to seller banner ads or video ads, Gombert pointed out, leaving open a loophole for in-banner video arbitrageurs that represent display inventory as video inventory.

“Display-to-video arbitrage is not necessarily solved by this, but it starts the conversation,” Gombert said.

Adding markers to include inventory type could become part of further iterations of ads.txt, Gombert said. For now, it’s taking public comment on the tool before it goes live.

IAB Tech Lab partners contributing to ads.txt include:
 
Per Bjorke, senior product manager, Google
Drew Bradstock, SVP for product, Index Exchange
Jim Butler, VP for engineering, Publisher Platforms, AOL
Andrew Casale, president and CEO, Index Exchange
Sam Cox, group product manager, AdX buy side and policy, Google
Jennifer Derke, director of product, programmatic and data, IAB Tech Lab
Allen Dove, CTO, SpotX
Alanna Gombert, SVP for technology and ad operations, IAB; general manager, IAB Tech Lab
Tamer Hassan, CTO, White Ops
Dan Kaminsky, chief scientist and founder, White Ops
Curt Larson, VP for product, Sharethrough
Pierre Nicolas, product manager, Criteo
Rachel Nyswander Thomas, VP of operations and policy, Trustworthy Accountability Group
Shree Madhavapeddi, product manager, Google
Neal Richter, consulting data scientist, Hebbian Labs​
Bill Simmons, CTO, DataXu
Scott Spencer, director, product management, Google
Sam Tingleff VP, buyer engineering, Rubicon Project
Ian Trider Director, RTB platform operations, Centro
Mike Zaneis, CEO, Trustworthy Accountability Group​

5 Comments

  1. Aden Forshaw

    It's great to see vendors being pushed to work with publishers directly and actually demonstrate & justify their value, instead of just exploiting inefficiencies through arbitrage.

    There is still a need to add verifiable crypto into the bidrequest to register the origin on a per-request basis, but this is an excellent start.

    Looking forward to the debate about similar solutions for protecting publishers first party data too.

    Reply
  2. Excellent idea and a very clean implementation. Eager to see how new features are rolled out to use this. Just curious about how soon publishers will get onboard.

    Reply
  3. It's a good solution, but just playing devil's advocate here: what's to prevent a motivated fraudster from simply crawling the sites they're looking to spoof themselves, grabbing an authenticated seller ID & domain from the ads.txt list and injecting that seller data into a subsequent bid request that they send off to another authenticated seller?

    This wouldn't be possible with a server-to-server integration with an exchange, since you can simply verify whether the server sending the request matches the seller ID present in the ads.txt file for the URL. But not all supply-chain integrations are strictly server-to-server so I'm curious how participating exchanges will be verifying ads.txt metadata that's inbound to THEM.

    Reply
    • Ben, If I'm understanding ads.txt correctly, wouldn't payment still go to the originating, authenticated Seller ID, making that strategy useless?

      Reply
      • There's nothing in the proposed spec about how payments are handled, as each participating exchange ostensibly handles payments differently. But regardless, all payments are going to be based one way or another on exchange DB records, which suggests that exchanges must enforce check for EVERY incoming request that the server IP (for server-to-server, resold / header bid requests -- this wouldn't work for client-generated bid requests, i.e. tags on a page) matches a pre-approved IP whitelist for a particular seller ID. Either that, or they enforce much stricter auditing processes when they process monthly payments to detect any discrepancies like this.

        Either way, it puts a lot more of the auditing burden on exchanges, and even with proper auditing in real-time or in batch, I still think it's probably possible to send a request from a client to an exchange server with a bogus Seller ID and get away with it, just like its possible to send a request with a bogus URL.

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>