Blockchain is often lauded as the next-generation panacea for all of ad tech’s ills.
While the verdict is still out on that one, there have been some amazing projects in the wild (What Can Blockchain Really Do for Advertising in 2020?) testing the technology’s viability for cleaning up the supply chain.
The CryptoRTB protocol was recently launched by AdLedger, to address widespread industry problems. The open-source technology injects cryptographic tools such as digital signatures into OpenRTB protocol to identify illegitimate ad supply, create a verifiable chain of custody, and create mechanisms for data access and validation for the digital advertising industry.
We chatted with AdLedger’s Executive Director, Christiana Cacciapuoti, to learn more about the problems that CryptoRTB solves in the supply chain, how it benefits both sellers and buyers, how it differs from ads.cert, and the results of tests using the protocol that prove that blockchain-based solutions can accommodate the speed and scale of ad tech.
Lynne d Johnson: How does the CryptoRTB protocol work with OpenRTB and what problems does it address in the advertising supply chain?
Christiana Cacciapuoti: CryptoRTB is an open-source extension to OpenRTB protocol that uses blockchain and cryptography to increase the integrity of the digital media ecosystem.
In a nutshell, CryptoRTB allows parties to insert a cryptographic object into OpenRTB messages. That object consists of a cryptographic signature which allows everyone to validate that the sender of the message is who they say they are, as well as encrypted data the originator would like to certify as true.
This makes it a very flexible protocol, able to solve lots of issues. To start, by simply including a cryptographic signature and a domain, we can eliminate fraudulent domain spoofing.
Once we have that technical proof of counterparties, we can start cryptographically linking the signatures to create a verifiable chain of custody which will help cut out arbitrage, make privacy compliance easier, increase media efficiency, and decrease data leakage. From there, we can start setting up sophisticated mechanisms for how we access and validate data.
Cryptography has been a critical part of providing security on the internet for decades. Identity of domains are registered using a similar process, with a neutral third party like Digicert issuing SSL certificates. In this case, AdLedger acts as the neutral third party issuing cryptographic keys.
LdJ: At a high level, how will CryptoRTB benefit both the sell side and the buy side?
CC: All legitimate players benefit from increasing the integrity of the ecosystem.
The sell side has a lot to gain. Arbitrage of inventory and data have been devaluing the publisher’s core product—their audience—for years. Fraud has stolen dollars that should be theirs. The disappearing ad dollar that we reference when we talk about high fees from middlemen is really disappearing publisher revenue.
Publishers are often caught in a catch-22. Advertisers ask that they share all the data they have on a given ad opportunity so that they can make an informed decision as to whether or not they want to buy. But as soon as the publisher accommodates that request, anyone listening to the bidstream can see the data they share.
In other words, there is no layer of control for publishers to decide who should get what data associated with which ad requests. CryptoRTB provides them with that layer of control.
For example, the publisher could decide to include the DeviceID in the encrypted object and only allow specific parties they give permission to decrypt it.
The buy side has a lot to gain as well. They have a lot of the same problems I mentioned earlier with fraud and media efficiency. Reducing fraud and shady middlemen will stretch their budgets and increase the effectiveness of their campaigns.
Creating a more intimate relationship between publishers and advertisers could also open up avenues for a better understanding of the validity of the data we are using.
Creating a more intimate relationship between publishers and advertisers could also open up avenues for a better understanding of the validity of the data we are using. For example, there’s no real understanding of what makes someone an “auto intender.” What action did they take to make us think they were in the market for a car? Were they in the market for a car in the last 30 days? 90 days? A year?
With CryptoRTB, publishers could include data like provenance and recency of the data in the encrypted object and share with a selected group of partners. Or they could encrypt an identifier like a DeviceID, MAID, or user agent and allow only a specific data partner to decrypt it. The data partner could remove the identifier and replace it with a behavioral segment before passing it to the buyer.
LdJ: I know CryptoRTB leverages the MadNetwork blockchain. What does this mean for the layperson who has no understanding of blockchain or cryptography?
CC: In a nutshell, it means security. It means that we can create technical proof that something is true instead of just trusting self-attestation.
To get more specific, we use cryptography to create a digital signature. A digital signature is exactly what it sounds like—a signature you use online to prove who you are and sign messages. It consists of two parts: a public key and a private key.
The public key is—you guessed it—public. It is shared with everyone in the ecosystem. The private key is closely guarded and not shared with anyone. The trick is that you can only produce the digital signature if you have both the public key and the private key. This makes the digital signature nearly impossible to forge.
The blockchain is used as a key-value store. That’s just a fancy way of saying that we use it as blockchains are intended to be used: as a shared, public database. In CryptoRTB, the information that we’re storing in this public database is the public keys.
This makes it so that anyone in the ecosystem can validate the identity of an actor in the ecosystem in real-time. For example, if I check the blockchain and know that Publisher A’s public key is 123abc, and I get a request from an entity claiming to be Publisher A but their public key is abc123, we know that it’s likely fraudulent.
LdJ: You’ve run some CryptoRTB pilots with AdLedger members, including an OTT scenario with a DSP and SSP. What have been some of the primary findings so far?
CC: The primary findings have been really exciting, but we are certainly not done yet.
We did a pilot with an SSP and a DSP creating those digital signatures I talk about above on behalf of their customers in production. This was a significant milestone because it proved that CryptoRTB could accommodate the speed and scale of ad tech, which is what most people think is the biggest obstacle to implementing blockchain-backed solutions in media.
While this milestone was exciting, it wasn’t the end game. Allowing your partners to create the digital signature on your behalf is kind of like giving a friend power of attorney. You trust your friends, but you probably want to sign your own important documents. Our next projects take the signature out to the edges, with publishers and advertisers signing on their own behalf.
We also recently partnered with Verizon to power Full Transparency, the corporate transparency initiative that creates a blockchain-verified record of changes to their press releases. The goal is to validate that a specific entity said a specific thing at a specific time. CryptoRTB is the infrastructure that validates the first part of that—in this case that Verizon is Verizon.
LdJ: Is CryptoRTB hard for publishers to implement and how does it compare with ads.cert?
CC: Nope! We know how precious technical resources are for publishers so we specifically designed it to be super easy to implement.
The process is pretty much the same as implementing a new tag. You just drop a couple lines of code into your core infrastructure—either your ad server or your SSP—and it creates the digital signatures for you dynamically. If you wanted to, you could check out the open-source code and build an application on top of it like Verizon did with Full Transparency. Think of it as you think of OpenRTB itself—a very flexible open-source protocol, designed to do many things—some of which we haven’t even thought of yet.
There are a few key differences between CryptoRTB and ads.cert. CryptoRTB is backwards compatible with OpenRTB 2.x and forward compatible with OpenRTB 3.0, while ads.cert is only available to those that upgraded to 3.0.
CryptoRTB works wherever programmatic is served, while ads.cert doesn’t support in-app or CTV. Because of the specific types of cryptography we selected, CryptoRTB is about 25x faster than ads.cert and because time is money in computing, it’s a lot cheaper to run. Finally, there are still some open questions around how to secure the private key in ads.cert whereas we’ve solved the security issue by rolling up to the blockchain.
LdJ: With privacy regulations like CCPA and CPRA already in motion and more states ready to pull the trigger on their own privacy regs, can you tell us about the privacy-compliant aspect of CryptoRTB and why that’s important?
CC: Privacy is only going to become more important as more states create their own regulation and the federal government contemplates their own action. There are a few ways I see CryptoRTB helping with this.
The first is that the verifiable chain of custody and auditable record of who was part of an ad transaction and how they participated will make it easier to spot if anyone in the chain dropped or manipulated a consent string. There’s been some great reporting on ways consent string manipulation is opening a new and critical front in the fight against fraud.
The second is that the encrypted object can create technical enforcement of user consent. A publisher could include all user data in the CryptoRTB encrypted object and only give permission to decrypt it to the parties with whom the user has consented to sharing.