What is Ads.cert and How Does It Work?

Despite all the advancements in the online advertising industry over the past few years—header bidding and the increase in programmatic ad spend, for example—there are still a number of fundamental issues plaguing the industry. Two of the main problems are the constant battle to reduce ad fraud and a growing need for transparency.

While both issues won’t go away overnight, there are a number of initiatives that are slowly making headway in resolving these issues—ads.cert is a prime example.

What is Ads.cert?

Ads.cert is the Interactive Advertising Bureau’s (IAB) fresh upgrade to the ads.txt set—the acronym stands for “authorized digital sellers”. The update ensures higheren transparency of the programmatic ad-buying process and stamps out some of the main issues of ads.txt by introducing cryptographically signed bid requests. It authenticates a publisher’s inventory and allows buyers to track the path of inventory to make certain they’re only purchasing from authorized sellers. This is all to curtail ad fraud and arbitrage, two phenomenons which have permeated online advertising for years.

It is estimated that companies investing in online advertising might be losing about a third of their advertising dollars to invalid traffic. The trend is on the rise, and new channels like mobile ads, video ads, and OTT are only presenting new opportunities for fraudsters.

There are many other types of ad fraud (we’ve written about them in one of our previous posts), and some of them may be very hard to detect and prevent.

While the possibilities to fully protect advertisers are still relatively limited, ads.txt and ads.cert aim to eliminate one type of ad fraud—domain spoofing—and can also help eradicate the shady practice of arbitrage, a process where impressions are purchased from publishers and then repackaged and sold at a higher price.

What is Ads.txt?

To minimize fraud and guarantee greater transparency in programmatic ad buying, the IAB Tech Lab developed ads.txt, a solution that verifies resellers of ad inventory. The way it works is really simple: the ads.txt file is added to a publisher’s site by its administrators and the file acts like a whitelist of partners (i.e. supply-side platforms and ad exchanges) that are allowed to sell the publisher’s inventory. We’ve written about ads.txt in one of our previous posts.

Programmatic buyers search the web for available ads.txt files and compile a list of “whitelisted” sellers for each participating publisher. Programmatic buyers set up filters that check their ads.txt against the data provided in the OpenRTB bid request.

amazon-adsystem.com, 3030, DIRECT
appnexus.com, 3661, DIRECT
facebook.com, 907986699290885, DIRECT
facebook.com, 1517497888551829, DIRECT
facebook.com, 785027118203148, DIRECT
google.com, pub-4177862836555934, DIRECT
google.com, pub-9542126426993714, DIRECT
indexexchange.com, 183760, DIRECT
indexexchange.com, 184733, DIRECT
liveintent.com, 130, DIRECT
openx.com, 537145107, DIRECT
openx.com, 539052954, DIRECT
openx.com, 539936340, DIRECT
rubiconproject.com, 12330, DIRECT
rubiconproject.com, 17470, DIRECT
yieldmo.com, New%20York%20Times, DIRECT
yieldmo.com, 1364526672772446209, DIRECT

The above example of an ads.txt file is hosted on www.nytimes.com. Because it’s the publisher’s domain, the file can be trusted.

In the open exchange, if the seller’s ID matches the ID in the file, the demand-side platform (DSP) can place a bid. It’s like like saying, “We know this ad exchange and trust their ads.” Ads.txt provides a unique ID for each seller partner, and third parties that are not on the list are not allowed to push ads to the publisher’s site.

Despite the benefits, there are a few issues with ads.txt:

• Simple misspelling of the content inside the ads.txt file means that buyers like DSPs have ignored the inventory.
• The inventory type is not always specified, meaning display inventory can be repackaged and sold as video inventory, and therefore wrongfully increases CPMs for publishers.
• Publishers are being asked to add unknown third parties to their ads.txt list.

Enter ads.cert.

What is Ads.cert For?

To solve some of the problems associated with ads.txt, IAB has devised another solution: OpenRTB 3.0 Authentication via Signed Bid Requests, aka ads.cert.

Unlike ads.txt, ads.cert is not a file, strictly speaking, and rather than supersede ads.txt, it was created as a complement. While ads.txt is a file that validates supply-side platforms (SSPs) and ad exchanges, ads.cert validates the information being transferred from the buyer to the seller at each stage of the process.

In the open exchange, buyers make their decisions based on various pieces of data:

• Publisher’s domain
• User location
• User’s IP address
• User’s device
• Ad’s position on page
• Impression type
• Other variables

With the rise of various ad-fraud methods, it has become very easy for fraudsters and bad actors to manipulate these variables along the supply chain and make bad inventory look like more premium inventory. Ads.cert is intended to stop that from happening.

Benefits of Ads.cert for Publishers (Sellers of Ad Space)

• More control of the inventory and the ads displayed.
• A way to “blacklist” bogus inventory sellers and thus eliminate “unfair” competition.
• Higher prices of ad space due to more overall transparency of the programmatic industry, resulting in better value of the ads.

Benefits of Ads.cert for Advertisers (Buyers of Ads)

• A way to identify authorized publishers, completely free.
• Better value for the advertiser’s money in programmatic buying, resulting in more effective ads.
• Elimination of the risk of ads being displayed on fraudulent or shady sites.
• A way to expose attempts to repackage display ads as video for higher monetary gain.

How Does Ads.cert Work?

Ads.cert is a way to cryptographically sign bid requests. It requires every stakeholder in the ad supply chain to use an encrypted signature. Both the inventory is cryptographically signed, and a matching public key has to be used by buyers to confirm that the source of the inventory is legit.

It enables tracking the inventory’s path and authenticates it to make sure the ad request hasn’t been changed by a fraudster, and the ad that reaches the publisher is legitimate.

The ads.cert encryption is based on two keys: public (disseminated widely), and private (known only to the publisher). Because both keys are needed to authenticate and decrypt the bid request, this method accomplishes two goals:

Authentication, where the public key verifies that the holder of the private key actually sent the bid request.
Encryption, because only the private-key holder can decrypt the bid request encrypted with the public key (e.g. to make any changes to it).

Publishers (or their AdTech partners) communicating with exchanges create a signature for a bid request that will then be re-transmitted by the ad exchange/SSP.

Here’s how the process works, step by step (steps based on the IAB Tech Lab’s documentation):

• OpenSSL’s security software is used by the publisher to generate a pair of ECDSA keys based on the bid request:
  • Public (secured, yet accessible, to be read by systems which validate the bid request against the signatures). The Public Key file must be shared via HTTP and/or HTTPS from the publisher’s website under a relative path on the server: /ads.cert. Although ads.cert is referred to as a file, the resource does not need to come from a file system.
  • Private (secret, secure, and inaccessible to outside systems, yet accessible to the systems that generate and sign bid requests, e.g. SSP). Private keys are in a standard format known to compatible security packages.
• An encrypted signature based on the bid request is generated with a private key and attached to the bid request and sent out on behalf of the publisher by an SSP, with details about the impression available, publisher’s website or app, industry, language, etc.
• The recipient of the request will then use the public key to generate another signature for that same bid request.
• The signatures generated by the publisher and by the recipient are compared to check if they were generated based on the same bid request (created using a matching pair of keys). If yes, then the bid request is considered legit. Any alterations of the signed elements can be detected by the recipient or other servers in the chain.

Challenges of Ads.cert

Despite being an improvement on ads.txt, there are still a few challenges:

• Ads.cert only works with OpenRTB 3.0, which is stopping it from widespread adoption as vendors need to invest in development of their platforms. Also, since OpenRTB 3.0 is not backward compatible, it cannot be used with existing technology. It will take some time before DSPs, SSPs, and ad exchanges become fully compatible.
• As in the case of ads.txt, the success of ads.cert vastly depends on its adoption rate.

Final Thoughts

Although the net impact of ads.cert depends on its wide adoption, encrypted bid requests are a sensible step forward and a much-needed addition to ads.txt.

The relatively fast spread of ads.txt may bode well for the industry-wide popularity of ads.cert. This may significantly curtail certain areas of ad fraud and dishonest behavior by some players in the online advertising industry – provided AdTech companies invest in updating their platforms OpenRTB 3.0 (currently released “for public comment”).

And while the transition from OpenRTB 2.3 to 2.4 or 2.5 was a seamless one, and ads.txt is currently widely used among the largest producers, the adoption or OpenRTB 3.0 version may pose more challenges due to lack of backward compatibility.