Will Ads.cert Be The IAB’s Next Big Inventory Clean-Up Play?

Both the adoption of Ads.txt and commercialization of blockchain solutions have the IAB optimistic about the prospects for Ads.cert, a follow-up to Ads.txt that uses cryptographic security measures to authenticate inventory.

While Ads.txt helps authorize inventory sources, it doesn’t solve the authentication problem, said Neal Richter, CTO of Rakuten Marketing and co-chair of the IAB’s openRTB working group.

There’s a subtle but important difference between authorization and authentication. Authorization grants permission to enter a designated area, but if an entity isn’t properly authenticated, it might gain entrance when it shouldn’t.

Ads.txt is a good tool to authorize inventory and avoid domain spoofing, but its loopholes have already been exploited by ad tech and media companies.

Some tech vendors have pressed publishers to add them to Ads.txt files to continue reselling inventory. And ad fraud researcher Augustine Fou said he’s seen networks of scam publishers add their own Ads.txt files or duplicate the Ads.txt page of reputable players to continue selling garbage inventory on lax DSPs.

“Just because there’s an Ads.txt file doesn’t mean it’s valid as intended or that it’s actually enforced,” Fou said.

Ads.cert would address this problem by creating a “signature process” that would certify whether a unit of inventory came from a verified publisher, Richter said.

The openRTB stream can’t currently guarantee the validity of inventory as its passed from server to server because, according to Richter, there’s “no way to sign inventory so that it can’t be changed.”

With Ads.cert, publishers could include an encrypted signature on inventory that would match to a public key used by buyers to confirm the inventory source.

“The roots are similar to blockchain,” Richter said, but instead of using a distributed ledger – which guarantees security on a blockchain – the IAB’s solution poaches only the idea of public and private encrypted keys to transmit bids along the supply chain.

“I’m skeptical of some of the claimed usages of blockchain in real-time advertising,” Richter said. “But the question is, would it be useful in other ways to validate content?”

Richter compared Ads.cert to the successful effort to stamp out email fraud in 2004 when signature confirmations were instituted between email servers. Before that protocol change, known as domain keys identified mail, fraudsters could disguise the source of emails.

“If you operate a spam server and now have to sign the headers, bad guys won’t do that because it tracks back to them,” Fou said.

There’s still a good deal of time and effort before Ads.cert is a viable product, however. Later this month, Ads.cert will enter its second phase of public comment and review, and next year the group hopefully will begin coding and validating the technology, Richter said.

“Many of us in ad tech have spent years building systems to look for bad activity, and it’s a game of whack-a-mole where you solve a problem and create a problem,” he said. “After a few cycles of that, you have to try and engineer a better solution.”

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!

1 Comment

  1. Ian Trider

    “And ad fraud researcher Augustine Fou said he’s seen networks of scam publishers add their own Ads.txt files or duplicate the Ads.txt page of reputable players to continue selling garbage inventory on lax DSPs.”

    Duplicating the ads.txt file of a real publisher will do nothing for the scam publisher. Ads.txt should be read in one direction only — that is, when a bid request contains domain “cnn.com” and is from publisher ID “1234”, the DSP checks cnn.com/ads.txt to see if 1234 is an authorized source. No inference should be made that if a certain exchange + publisher ID is found in CNN’s ads.txt file, it is somehow a “good” one, merely that CNN is saying that as far as they are concerned, it is an authorized source of CNN.com inventory.

    If cnn.com’s ads.txt file is placed on badsite.com, it does not help badsite.com misrepresent itself as CNN. The bad actor might be able to spoof the domain that the exchange sends out in bid requests, but the publisher ID is not under their control. So, if their publisher is is “5678”, their cnn.com bid requests on the exchange will indicate publisher ID 5678 which not match cnn.com/ads.txt, and DSPs will not bid.

    Their only options are to either actually sell the inventory of badsite.com as badsite.com (in which case they can have their ads.txt file confirm that badsite.com is an authorized source of 5678, but they have to call it badsite.com which successfully undermines their ability to fake the impression as something else), or actually hack into CNN’s web server or trick CNN’s people into inserting a record for publisher ID 5678 into the actual cnn.com ads.txt.

    The last — the social engineering risk — is one we should all be aware of. Publishers should NEVER insert a record into their ads.txt file because they received an unsolicited request by e-mail.