Authentic Connections: Ads.Cert and Protecting SSAI

Some days, working to protect the digital advertising ecosystem feels a bit like playing UNO. I know, it’s a weird analogy, but go with me for a moment: you’re trucking along, doing your thing, getting it done, when all of a sudden, there’s a big change in the rules and you have to change how you’re approaching what’s happening in front of you.

SSAI was a bit of a draw four, if you will. No longer could protection technology see an IP address associated with a data center and automatically assume the traffic was invalid, nor could legacy protection technology like tracking pixels be as useful. It’s a great technology from a user experience perspective: broadcast quality, seamless, buffer-free ad breaks. But the server-to-server communication that underlies the technology makes it a target for bad actors.

The IAB Tech Lab’s ads.cert initiative validates those server-to-server interactions at the speed of digital advertising, making it a crucial weapon in the fight against SSAI spoofing. When the IAB Tech Lab was building the program, they kept three design principles in mind:

1. Privacy first. Ads.cert must not create a cryptographic record of consumer or business activity.
2. Exclusivity. Ads.cert must not enable third parties to interpret or infer any information from the technology; the digital signature must only be usable by the party(ies) intended to use it.
3. Plausible deniability. Ads.cert must not be usable as proof an activity occurred. The technology must be symmetrical, meaning the “shared secret” signature (more to come on that in a moment) is the same no matter which of the two parties creates it; the originator can not be indisputably identified.

The intention here is clear: build a program that brings clarity to server-to-server connections.

Here’s how ads.cert 2.0 works:

1. A Private Key is created using the ads.cert open-source software. Each Private Key is a very large, 256-bit random number that’s kept confidential.
2. A formula is applied to the Private Key, creating another 256-bit random number. This corresponding second number is a Public Key, which is published on DNS so other entities can find it.
3. When two parties want to mutually validate the authenticity of their server-to-server connections, they have a key exchange using a cryptographic algorithm. Party 1’s Private Key is combined with Party 2’s Public Key, creating a digital “shared secret”. And it works in reverse, too - if Party 2 uses their Private Key to compare with Party 1’s Public Key, the “shared secret” is identical. That’s what the Tech Lab means by “symmetry”.

Adoption of ads.cert has been slow, unfortunately. It’s a critical piece of the puzzle in protecting CTV ad dollars (more on that in a future post), but on its own, it helps resolve the challenges of SSAI as a low-signal delivery mechanism and assures both sides of a given connection can mutually authenticate.

All this is to say: HUMAN and the Human Collective are big supporters of the initiative. Ads.cert closes a gap in industry countermeasures to fraud. It is imperative that your platforms, vendors, and buying paths incorporate ads.cert 2.0 Authenticated Connections in order to protect CTV ad investment.