Ad fraud and invalid traffic (“IVT”) can take on many forms, but falsified information in the bid request is one of the most common challenges. The IAB’s upcoming ads.cert initiative aims to address such challenges by creating a validated, public chain of command.
If you think of a programmatic ad transaction as a huge game of telephone — in which many different players have access to the message from Point A to Point Z — ads.cert essentially allows the final player (the buyer) to validate the original message with the first player (the seller).
Pixalate fully supports the IAB’s ads.cert initiative and we intend to keep you apprised on adoption trends and all future related ads.cert news.
Ads.cert is part of the OpenRTB 3.0 framework, which, in the IAB Tech Lab’s own words, is focused on “secure supply chain standards.”
The IAB says the OpenRTB 3.0 framework “is the largest overhaul of the OpenRTB protocol since its inception in 2010,” and that “[t]he purpose of this major update is to meet the market’s demand for security, transparency, authentication, and trust in programmatic advertising.”
One of the major changes in the new protocol is “a signed supply chain to enable the demand side to validate many of the fields in the bid request and to have a clear chain of custody.”
Those signed bid requests are what people refer to when they say “ads.cert.” Here is the IAB tech Lab’s document that goes into “Signed Bid Requests” in greater detail.
Think of it as a complement to the existing ads.txt initiative, which has seen widespread adoption since it launched in the summer of 2017. Ads.cert is meant to complement ads.txt — not replace it.
Ads.txt was designed to reduce “spoofing” in the open programmatic marketplace for desktop display advertising. Spoofing is when one site (often a lesser-known site) pretends to be a different site (often a well-known site) in order to increase the perceived value of the inventory they sell. But ads.txt has limitations.
While ads.txt does validate that certain sellers are authorized to sell certain publishers’ ad inventory, it does not validate any information about the inventory itself.
When an impression is traded in the open programmatic marketplace, all sorts of data points are shared with the buyer. Many buyers decide whether or not to buy the inventory (and for how much) based on some of these factors. Some of the data points shared include:
How ads.cert helps: Ads.cert validates the inventory via a signed “chain of custody” report. This means buyers will be able to check ads.txt to confirm the publisher on which the inventory is available and use ads.cert to confirm certain data points about the inventory.
This is more of a subset of the section above, but it’s worth highlighting on its own since it’s a common issue in the digital display marketplace.
Because ads.txt does not validate the ad type, resellers can take a display impression and sell it as a video impression. Here’s what MediaPost wrote on display-to-video arbitrage in a recent article, citing research from Pixalate in conjunction with OpenX:
"The blocky 300x250 banner ad has long been one of the most common ad units in the display advertising marketplace, but thanks to some ingenuity, cunning and outright fraud, it has also become one of the most common video advertising units sold via programmatic ad exchanges."
Ads.cert will introduce a few new words to the programmatic ad industry’s dictionary, including “keys,” “signatures,” and “messages.”
The IAB Tech Lab uses the term “message(s)” to refer to OpenRTB bid requests. We will use the same terminology.
The message contains information about the inventory, such as device type, ad type, IP address, browser, operating system, and more.
The IAB notes that each message “needs to have something unique (a random message identifier) to the message to prevent reuse of the message and signature by a downstream system.”
The ads.cert initiative asks publishers (or a designated partner; more on that below) to “sign” the message in order to validate the information included in the message. The signature is created by stringing together all field values for a given request.
The IAB shares the following example:
The guidelines note:
“For the sample values in the table, the input string into the signature would be as follows:
ABC7E92FGD6A;12345678;newsite.com;;192.168.1.1;;
That string would be used to create the signature string which would be inserted into ps (in the case of generating the request) or checked against the value that is received in ps (in the case of validating the request).”
Public key: Per the IAB, publishers are required to make a public key file accessible via HTTP and/or HTTPs (similar to how ads.txt works). The IAB adds: “Note that the public key must be secured yet accessible to be read by outside systems to validate the messages against the signatures.”
The public key will be used by buyers to confirm the message (e.g. confirm the inventory).
Private key: The private key is encrypted and should only be accessible to the publisher (or designated partner), as it is needed to generate and sign messages.
When a publisher has an available ad impression, the publisher/SSP will build the bid request (“message”), create the signature based on the information in that message, and sign it using the private key. As noted by the IAB, “No downstream system can make changes in the signed fields.”
The advertiser/DSP can then use the domain’s public key to authenticate the message. Per the IAB, this can be done in real-time or offline.
The IAB notes that there are two ways in which messages can be signed:
In both scenarios, the IDs and domains can be validated via ads.txt while the message and signatures can be validated via ads.cert.
It should be noted that of this writing, the ads.cert initiative is still in a period of public comment. Additionally, ads.cert will require OpenRTB 3.0 support.
Furthermore, as of the IAB’s September 2017 framework, ads.cert did not fully support mobile in-app because “signatures are not fully supported due to the lack of a reliable method to retrieve the public key since there is no known domain.” The ads.txt initiative faced a similar issue within the mobile app ecosystem, but the IAB appears to be making progress in this area: In early June 2018, the IAB Tech Lab released its first guidance for the use of ads.txt within mobile apps.
When the ads.cert initiative is officially released, Pixalate intends to track its adoption.
Want more data-driven insights? Sign up for our blog!
