The world of programmatic ad buying is increasingly threatened by ad fraud. This includes fraudulent representation of ad impressions and clicks, or manipulation of bid requests for monetary gain. Ads.txt came as a way to partly curtail the phenomenon, and the recent addition of ads.cert makes a robust countermeasure to fraud.
While the general consensus is that ads.cert is a newer version of ads.txt, it doesn’t exactly define the relationship between the two. In fact, ads.txt and ads.cert go hand-in-hand to combat ad fraud and serve completely different purposes.
Ads.txt aims to reassure media buyers that the inventory they’re buying is from the site listed in the bid request, while ads.cert adds an additional layer of authentication and transparency by cryptographically signing bid requests from publishers. Rather than superseding ads.txt, ads.cert is designed as a complement.
The Role of Ads.txt
The idea behind ads.txt is to curtail specific kinds of ad fraud:
- Domain spoofing: The phenomenon where fraudsters disguise themselves as renowned, premium publishers and try to sell their inventory, sometimes at lower prices.
- Illegitimate inventory arbitrage: A situation when less money goes to the publishers, and more goes to various intermediaries reselling inventory with a markup. Arbitrage can be partially eliminated by knowing the seller ID and verifying whether they are authorized to sell the inventory of a given publisher (although they can still buy and then resell the inventory under a different seller ID).
Ads.txt is a countermeasure for domain spoofing as it validates SSPs and ad exchanges. It is a simple file available from a publisher’s site that provides a “whitelist” of companies the publisher declares authorized to sell their digital inventory.
Without wide adoption, there is no way to make ads.txt consistently work across the industry. While adoption has been really fast—according to Ad Ops Insider, only 44% of ad-supported websites have adopted ads.txt—the majority of publishers still don’t consider ads.txt a priority. The slow rate of adoption gives no incentive to buy impressions from only ads.txt-verified sellers and resellers, at least for now.
We’ve written about ads.txt in a previous post on our blog.
The Problem With Ads.txt
The main problem of ads.txt is that it is not completely bulletproof anymore. It turns out that a solution in the form of ads.txt is just half the battle against domain spoofing. Fraudsters and shady third-party resellers are now are trying to trick publishers into adding them to their ads.txt files (often via real-person sellers contacting the publisher). If it happens, those same fraudsters and unauthorized resellers that were meant to be stopped in their tracks by ads.txt could end up going back to their old tricks, essentially defeating the purpose of ads.txt. The sheer volume and speed of programmatic ad buying makes it impossible to wield consistent control over the phenomenon.
This is where the function of ads.cert comes in handy.
The Role of Ads.cert
With the rise of various ad-fraud methods, it has become very easy for fraudsters and bad actors to manipulate the distribution of ads and the contents of ads.txt, not to mention the possibility of human error. Fraudulent activity can be disseminated around the supply chain and make bad inventory look like premium inventory. Ads.cert is intended to put an end to that.
In the open exchange, buyers make their decisions based on various pieces of data about the publisher’s inventory. Ads.cert validates the bid-request information, including:
- Publisher’s domain
- User’s location
- User’s IP address
- User’s device
- Ad’s position on page
- Impression type
- Other variables
The whole idea of ads.cert is to cryptographically sign bid requests. To learn more, please read our post about ads.cert. Basically, with ads.cert in place, two keys are generated by the publisher: public key (disseminated widely), and private key (known only to the publisher).
In this way, both the inventory is cryptographically signed, and buyers must use a matching public key to confirm that the source of the inventory is legit. Bid requests are:
- Authenticated, where the public key verifies that the holder of the private key actually sent the bid request.
- Encrypted, because only the private-key holder can decrypt the bid request and make changes to it.
The Problems With Ads.txt Solved by Ads.cert
While ads.txt is a step in the right direction, the solution still does not guarantee 100% success. There are a couple of problems stopping it from ensuring full transparency in the system:
- While ads.txt is an effective means to verify the seller, it is still impossible to confirm that the inventory it has is what it’s supposed to be. By a real-life analogy, it’s like going to a genuine Gucci store, but the seller cannot guarantee that the products themselves are authentic.
- Counterfeit websites can still attempt to copy a legit publisher’s ads.txt and post it as their own, and possibly game some of the DSPs.
To read more about how ads.cert works, head over to another post on the Clearcode blog.
The Challenges of Ads.cert
As in the case of ads.txt, the main problem of ads.cert is a lack of industry-wide adoption. Currently, ads.cert is in the development phase, along with OpenRTB 3.0, which is still in the “draft for public comment” phase (the latest update as of publishing this article is from September 2017). Also, because OpenRTB lacks backward compatibility, we can’t expect the transition to happen overnight.
The benefits that the combination of ads.txt and ads.cert brings are impossible to ignore, and once they are widely adopted by publishers, they may be a complete game-changer in the programmatic ad-buying world.
