Ads.cert is the digital media’s latest effort to combat fraud

That trust loophole is expected to close when IAB Tech Lab officially rolls out OpenRTB 3.0, the industry standard framework that undergirds the automated advertising process. That official release is getting closer. After debuting the draft version of OpenRTB 3.0 for public comment in September 2017, the IAB Tech Lab will release a beta version of the specification on July 24, said IAB Tech Lab CTO Sam Tingleff.

OpenRTB 3.0 is pertinent to the potential for ads.txt fraud because it will include ads.cert, a process that will certify the authenticity of a publisher’s inventory through the programmatic chain of custody and address the potential for companies in the programmatic supply chain to pass off impostor inventory as the real deal.

“Ads.txt is sort of the store directory. It’s Rolex saying here are the authorized places to buy a Rolex. But the [authorized] store could be selling fake Rolexes on the side. Ads.cert is the certificate of authenticity traceable back to the manufacturer,” said Ian Trider, director of RTB platform operations at Centro and member of the IAB Tech Lab’s OpenRTB working group.

The certificate of authenticity provided by OpenRTB 3.0’s ads.cert “gets rid of the need to trust really anyone in the chain,” said Larson. Of course that’s contingent upon the official update’s release and ad tech firms’ adoption of it. Until then, there remains the loophole of trust that received attention earlier this month when it was highlighted by Forensiq, the ad fraud detection arm of ad tech firm Impact.

Forensiq claimed that mobile apps are able to masquerade as web publishers and trick ad exchanges and supply-side platforms into passing off their in-app inventory as another publisher’s authentic web inventory. However Forensiq’s loophole hinges on an exchange, SSP or the advertiser’s chosen demand-side platform not checking the publisher’s ads.txt file to determine that the mobile app is or is not the publisher it claims to be, as illustrated in the image below provided by Forensiq.

That contingency craters the argument that such a loophole exists, according to members of the IAB Tech Lab’s working group that handles ads.txt. Cross-referencing ads.txt files as inventory passes from publisher to various ad tech platforms to advertiser is “the whole point of the ads.txt spec,” said Tingleff.

For its part, Forensiq has not been able to prove that this type of ads.txt fraud has happened. But its aim was to show that it’s possible and to underscore the need for everybody in the programmatic supply chain to validate against publisher’s ads.txt file, according to Amit Joshi, director of product and data science at Forensiq. “The only way that [ads.txt is] truly effective is if everybody in the supply chain is validating,” he said.

That stipulation may seem obvious, but it may have been missed by anyone who has read ads.txt’s documentation and assumed that only the demand-side platforms that advertisers use are responsible for validating against publishers’ ads.txt files.

Stating in the ads.txt spec that all companies in the programmatic supply chain should assume responsibility for validating against publishers’ ads.txt files is “definitely something which makes sense to clarify in the next spec release. Creating specifications like this is always a process of continual improvement and we welcome participation in that process,” Tingell said.

“The nature of the ads.txt spec assumes that ultimately the validation has to live at the buy side. In other words, the buyer’s DSP has to be the entity doing the validating because intermediaries along the supply chain, their interest is not aligned in preventing the propagation of that [fraudulent] inventory,” said Ian Trider, director of RTB platform operations at Centro and member of the IAB Tech Lab’s OpenRTB working group.

Theoretically, if an advertiser’s DSP is looking to buy a publisher’s inventory from a certain exchange or SSP, it will be able to check that the exchange or SSP and its corresponding seller ID is listed on the publisher’s ads.txt file. If it is, then the inventory is likely authentic; if not, then likely not. But that assumes that the exchange or SSP is not falsifying that information in order to peddle inventory from another publisher posing as the intended one, such as by bundling the real and fake inventory together.

“What ads.txt really solves for is publisher fraud or maybe an ad network that they’re working with spoofing the domain. But if the exchange that the DSP is buying on is complicit in the fraud, literally being actively part of the fraud, then you couldn’t detect that with ads.txt,” said Larson.

None of the executives interviewed for this article were aware of any exchanges or SSPs that have committed this type of ads.txt fraud.