In a recent article in AdWeek, Forensiq shared findings that 1,400 mobile apps loaded ads while under the guise of TV Guide’s domain.
That raised a lot of eyebrows across the industry, particularly since the vaunted Ads.txt was supposed to put an end to such domain-spoofing tomfoolery. Forensiq suggested that those 1,400 apps were only the tip of the iceberg; AdWeek’s headline decried a “loophole” in IAB’s ad fraud prevention schemes.
But when I shared the story on Twitter, a few people were quick to ask: how exactly did these rogue mobile apps pull off such a feat? Since it wasn’t rigorously detailed in the AdWeek article, what exactly is this loophole?
No, there’s no flaw in Ads.txt—buyers simply aren’t performing due diligence.
Check Out This Scam, Man
Yes, mobile apps have been a blind spot for Ads.txt because they don’t have a domain to store a text file for easy crawling. The IAB currently has guidance for implementing Ads.txt in the app environment up for commentary.
So while many web publishers are increasingly forced to submit an Ads.txt file to get onto exchanges and be viable to buying platforms, mobile apps are not held to the same standard.
As explained by the ever-resourceful ad fraud researcher Dr. Augustine Fou, the mobile app fraudsters will load hidden web-view browsers with altered HTTP headers and bid requests. Spoofed addresses for premium publishers are the most common as they tend to draw higher CPMs.
The mobile app fraudsters jump on the same exchanges as premium publishers because they too can read the Ads.txt files, and then they go fishing. It goes something like this:
- Scam mobile app creates a hidden browser with a spoofed domain for PremPub.com
- This browser sends a bid request for the spoofed domain to Exchange X, which is an authorized reseller of PremPub’s inventory.
- The ad is actually served within the Scam mobile app—potentially on an empty “page.”
Thus money in the scammer’s pocket… unless the buyer verifies that the seller ID in the bid matches the seller ID in the Ads.txt file. Wait, you say—shouldn’t the buyers be doing that in real time, potentially through their DSPs? Yes, that was the whole point of the Ads.txt file—buyers would validate that the impression coming through the exchange had the same publisher ID as the Ads.txt file.
But fraud persists—not just within mobile in-app advertising—because buyers may check to see if certain publishers have Ads.txt files, but they are not regularly scanning them. If they don’t perform this task, we’re in the same place as before Ads.txt.
Is Ads.txt Enough?
Ads.txt is a limited solution focused on domain spoofing and unsanctioned inventory arbitrage. It’s supposed to be very basic and easy for both publishers to implement and DSPs to crawl. It’s almost too basic—many a pub needed an Ads.txt validator to ensure their file was viable and not hampered by spelling errors.
The majority of premium publishers, many under the threat of expulsion by their ad tech and demand partners, have done their part, but too many of their buying counterparts are failing to pull their weight. There seems to be a widespread misconception that premium publishers installing Ads.txt files simply killed domain spoofing. Nope—Fou notes that fraudulent web publishers can put up fake or plagiarized Ads.txt files to meet the requirements of exchanges and DSPs, but still send spoofed domains of premium publishers into the marketplace.
Although they should be monitoring in real time, buyers and agencies should spend billing time reviewing not just domain lists, but also whether domains line up with correct seller IDs. But this extra step has not become commonplace. It doesn’t help that that the exchanges/intermediaries themselves derive revenue from all transactions—yes, Virginia, even the fraudulent ones—which lessens their incentive to expel domain spoofers for their marketplaces.
Thing is, Ads.txt was always supposed to be step one—and indeed it’s been a boon to players in the industry that have actually employed. But the persistence of fraud like domain-spoofing shows that the industry needs to move on to step two: authentication.
Authenticate Now
Ads.cert has been described as an update to Ads.txt, but it’s really an upgrade or an extension into new territory. Ads.txt validates the seller in ad transactions, but Ads.cert is a tool for transaction authentication.
Something akin to the DomainKeys Identified Mail (DKIM) signatures in email headers that were introduced to detect email spoofing, Ads.cert would enable publishers to include an encrypted signature on inventory. Buyers would then match that to a public key in real time to certify that their inventory appeared where promised.
Ads.cert is a key part of the soon-to-be publicly released OpenRTB 3.0, the biggest revitalization of the specification since its launch in 2010. There’s plenty of speculation that the intermediaries will take their own sweet time adopting OpenRTB 3.0 because… Well, there’s a strong likelihood that those with unsavory practices will lose hot revenue streams.
Publishers—particularly those that consider themselves premium—need to nip at their demand partners’ heels on this, and also make the importance of OpenRTB 3.0 clear to buyers. This type of fraud is shorting publishers on rightful revenue, and deceiving advertisers.
Before OpenRTB 3.0 hits the streets, publishers should be well versed in all the documentation out there about Ads.cert. But to help out their advertisers now, pubs should encourage agencies to make sure their buying platforms are checking Ads.txt files in real time. They could even go as far as to suggest only using the DSPs they know are acting in good faith—SPO!
Beyond that, agencies and other programmatic buyers need to insist on receiving reporting from exchanges and other partners that includes not just domain lists, but domain lists along with seller IDs. This way the people holding the purse strings can hold their partners accountable.