To anyone who labors under the belief that domain spoofing isn't a catastrophic problem demanding immediate action I have one word: Methbot. Created by a group of fraudsters overseas, Methbot spoofed 6,000 publishers 1, bilking marketing blogs (and publishers who were supposed to get that revenue) of some $3 to $5 millions per day.
And the problem isn't slowing down. In September 2017, the Financial Times released the results of its investigation into the domain spoofing its own site. To its horror, the publisher found “display ads against inventory masquerading as FT.com on 10 separate ad exchanges and video ads on 15 exchanges, even though the FT doesn't even sell video ads programmatically,” (emphasis mine). 3
Though it's difficult to state exactly how much money is stolen each year, it's fair to say it's a multi-billion dollar crime, and one that law enforcement has largely left to the victims to fight by themselves. Fortunately, we now have a strategy that can go a long way in doing just that: ads.txt.
What is ads.txt?
Ads.txt is the direct result of an IAB project to put an end to domain spoofing through transparency. As the IAB explains: “Ads.txt stands for Authorized Digital Sellers and is a simple, flexible and secure method that publishers and distributors can use to publicly declare the companies they authorize to sell their digital inventory.” 4
Basically, ads.txt gives the publisher the right to explicitly tell the demand side platforms (DSPs) who they've authorized to sell or resell their inventory. Thus, whenever a DSP that is participating or enforcing ads.txt receives a request for a bid from an ad exchange, it can check to see if that seller is truly authorized to sell that publisher's inventory. If not, that request is ignored.
How do publishers inform the DSPs who their authorized digital sellers are?
It's shockingly simple: publishers just post the “/ads.txt” file on their root domain and any subdomains as needed. The file lists all of the authorized sellers and re-sellers, along with a unique ID (assigned by the SSP) for each seller and reseller associated with the publisher. It's those IDs that inform the DSP whether or not the seller has a direct or indirect relationship with the publisher.
Does that mean the DSPs must proactively collect all the ads.txt files from every publisher?
Yes, but it's easier than it sounds. These lists can easily be found on the sites of any publisher that has one. The URL is the publisher's main page, with “/ads.txt”: publisher.com/ads.txt
Additionally, the IAB has actually produced a crawler that anyone can use to inspect publishers webpages to see if they have an ads.txt file live and understand all of the ID's and partners. Once in hand, the DSP will no longer honor bids from a requestor that's missing a verified ID (as long as the publisher has actually published an ads.txt file).
If the ads.txt files are public, can they be spoofed as well? What's to stop fraudsters from simply include it in their bid requests?
The unique IDs cannot be spoofed, because they're assigned to each domain by the SSPs and can't be suppressed or overridden. For instance:
Let's say I own NYTIMES.COM. I set up a relationship with SSP.com, and SSP.com assigns me a PUBID of 12345. I then include SSP.com 12345 Direct on my ads.txt file. Anytime SSP.com sends a bid request for this site, it will always include pubID with NYTIMES.com as 12345. Because I have created an ads.txt file, the DSPs will verify this with their crawler and buy from me because it checks out.
Let's say you own FAKENYTIMES.COM. You set up a relationship with SSP.com and SSP.com assigns you a PUBID of 67890. You instead attempt to spoof me by including 12345 on your ads.txt file. Even if you were somehow able to spoof the domain, SSP.com will still pass your assigned PUBID (67890) to the DSPs, which would not match what you put on your site, and they would not buy.
Will ads.txt work if publishers choose not to create and maintain an ads.txt file?
No, the publisher must create an ads.txt file in order for the authorization to occur. One of the downsides to this approach is the ads.txt files require upkeep on the part of the publisher. This upkeep may dissuade a publisher with numerous web properties and hundreds of sellers and resellers from implementing it right away.
Going up a level, the approach can only stop domain spoofing once and for all if the vast majority of premium publishers create and maintain ads.txt files. Until we reach a critical mass, domain spoofing will continue to be a serious crime.
What will it take for ads.txt succeed?
Success will be driven in large part by the DSPs and how they choose to adopt it as they are the ones that ultimately making the buying decisions on the exchanges. The biggest DSPs — most notably Google, — have made it known that they plan to implement ads.txt by November 1, 2017.
What that means, at least initially, is this: if a site has a live ads.txt file the DSPs will most likely respect those authorized digital ad sellers on that page, and only buy from those partners.
But if a website doesn't have an ads.txt file live it will treated as an unknown, but the DSPs may opt to buy it anyway, In other words, some DSPs may treat it as business as usual.
Why would a DSP continue business as usual when it's so easy to verify sellers and resellers?
Keep in mind that just because a publisher doesn't have a live ads.txt file it doesn't necessarily mean it's a risk to buy from the publisher. It may mean the publisher simply hasn't had the time to create an ads.txt file, or that believes that creating one during the business holiday season isn't prudent. Creating an ads.txt file, by definition, will require the publisher to assess each and every seller and reseller in their ecosystem. It is the perfect opportunity to evaluate the value each one brings, and whether or not the relationship should remain intact. This is a big job they may wish to put it off to Q1 2018, when advertising drops off.
And there are risks to the DSPs as well. Let's assume that a DSP opts to only purchase inventory from publishers with a live ads.txt file, but a substantial number of publishers have failed to create such files. That DSP will quickly run into scalability issues as it executes its campaigns going forward.
The challenge for the DSPs — and for the entire industry — is to roll out ads.txt in a way that's efficient, scalable, but doesn't defeat the purpose of it by buying both authorized and non-verified at the same time.
How many websites have adopted ads.txt?
It's difficult for me to say for certain; adoption was slow to begin, but has accelerated in recent months. As of October 2017, we have yet to reach mass adoption.
