• by Laurie Sullivan , Staff Writer @lauriesullivan, October 4, 2021

The IAB Tech Lab Cryptographic Security Foundations Working Group last week released the second version of its ads.cert framework to improve transaction transparency in programmatic advertising.

The framework supports additional layers of cryptographic security to reduce ad fraud within connected television (CTV), which eMarketer estimated will reach $13.41 billion by the end of this year.

Data & Programmatic Insider caught up with Shailley Singh, senior vice president of product management at IAB Tech Lab, to talk about the framework. Shailley has a diverse background working at companies such as PayPal, Yahoo, Say Media, Accenture, PwC and others. 

Data & Programmatic Insider:  Why is ads.cert 2.0 important?

Shailley Singh:  To further trust and have confidence in buying through programmatic channels, a level of security and integrity is needed within the buying protocols.

Buyers receive ad requests either through user devices or server-to-server communication performing on behalf of a user device — Server-Side Ad Insertion.

However, most server-to-server communications do not clearly identify the entity invoking the ad request, making it very difficult to identify if the ad request is from a legitimate ad-tech partner.

Ads.cert 2.0 solves this problem by creating a standard way for any client of a server-to-server request to authenticate itself with the server it is calling. The solution does this in a way that is compatible with existing web services for ad interactions.

Adding this form of security will significantly reduce the risk of having a fraudulent server-to-server ad integration evade detection.

D&PI:  How did the group identify the need and create the development specifications?

Singh:  This effort started when we looked at various ad fraud vectors and thought about how we can provide the industry with tools to help fight against them.

One of the tools we had provided in the past was the set of transparency standards — ads.txt/sellers.json/SCO — which helps us understand the entities involved in the bidding process.

With the use of CTV and streaming exploding in use during the last few years, we found the biggest concern was around Server-Side Ad Insertions, which is necessary for CTV, but it also opens the opportunity for bad actors to claim traffic from a set of servers instead of from end user devices.

There had been various discussions in the industry around managing IP address allow/blocklists and more, but none seemed practical. The working group recognized that the best path to handle this was to provide a secure mechanism to identify the SSAI vendor. This was the original driver for Authenticated Connections protocol.

We also recognized these capabilities would be useful in other scenarios, and so went about building generic specs that can be used elsewhere. Finally, we decided to build a set of open-source libraries to help the industry easily adopt these protocols. Now we have a good set of libraries on our GitHub repository to support ads.cert 2.0.

D&PI:  How does security and fraud protection for CTV differ from any other type of media like display or search advertising?

Singh:  Fraud protection for CTV differs from display or search. The origin of ad requests and technology are different.

In display and search, the primary method is client-side ad requests, built on well-known and open technologies like browser technology or mobile platforms such as iOS and Android, with well-defined APIs and environments that can execute client side code like Javascript.

In CTV, Server-Side Ad Insertion is much more common for better user experience. Many CTV devices may not allow client-side code execution or native code libraries--like mobile phones--are needed to perform fraud detections.

You need server-side protections from identifying the entity running an SSAI server to ensure it’s a legitimate party that is actually serving SSAI based ads. We also need capabilities to verify that the ad is actually delivered and account for different nature of user interactions on CTV for determining IVT. Today, we have OM SDK for native apps and web browser but there is nothing for CTV. We are developing and plan to release later this year OM SDK for CTVs.

CTV is a different medium. User interactions are different, display navigation and controls for content consumption is different than media on desktops, laptops, and mobile devices.

The nature of differences can lead into misrepresentation of inventory on existing programmatic channels and other content taxonomies to reflect movie/TV genres, so there is proper classification of content, which we released last week in Content Taxonomy 3.0.

In the upcoming revisions of Open RTB, we are working on releasing improvements to better represent CTV inventory, thus closing the loop on differences with display and search.