Post Bid SSP Macro Replacement: Spoofing Top Level Url

[dchristian-ias]

Assessment Today, in a Protected Audience auction, the SSP has the ability to replace macros on the renderUrl of the winning ad via deprecatedReplaceInURN.

In order to preserve post-bid brand safety for advertisers, verification vendors will rely on the top level URL to be provided via this macro replacement mechanism on the winning ad’s renderUrl in order to have access to this value from within Fenced Frames.

When ads are delivered via cross domain iframes, verification vendors have the ability to check ancestorOrigins to verify that, at the very least, the domain of the page matches the top level URL provided by this macro replacement mechanism (this applies to both traditional ORTB/Contextual auctions as well as Protected Audience auctions).

Problem Statement The introduction of Fenced Frames and the loss of the ancestorOrigins signal will prevent verification vendors from verifying the top-level URL provided by the SSP via macro replacement. This could lead to inaccurate post-bid brand safety and fraud detection results for advertisers.

Key Issues

1. Accuracy of Macro Replacement:

• The reliability of the top-level URL provided by the SSP through macro replacement is not ensured, posing a risk of spoofing or manipulation.

2. Loss of Verification Signal:

• The loss of ancestorOrigins in Fenced Frames creates a significant verification gap. Alternative methods need to be identified.

Questions

1. New Verification Mechanisms:

• What mechanisms can Chrome introduce to allow verification vendors to verify the top-level URL within the Privacy Sandbox framework?

2. Alternative Signals:

• Are there alternative data points or signals that can be used within Fenced Frames to ensure the accuracy of the SSP-provided top-level URL?

[michaelkleber]

There are a variety of different answers here, some of which you may find more or less desirable.

1. I would strongly recommend considering a pre-bid instead of post-bid approach. In the classic RTB context, post-bid has the natural advantage that it's the only time you can really be sure of what site you're on, because pre-bid the information that was passed along in the bid request is naturally subject to manipulation. But in the Protected Audience's on-device auction, pre-bid signals are the most reliable thing. Inside the PA bidding flow, the top-level hostname is guaranteed knowable by the browser.

2. For post-render, I would very much like to distinguish between knowing the top-level page's hostname and knowing its URL. We need to treat the page's URL as data that could include a user identifier, while a hostname is much safer. (The URL itself is also a less "true" signal from the browser's point of view, because history.pushState() means any JS on the page could change the path.)

3. For your use case, would you be content with the browser offering an API like "I believe I am on site X, please tell me whether or not that is true"? This would be much better for privacy than an API like ancestorOrigins that would put k-anonymity at risk.

4. You could already do some after-the-fact detection by writing a timestamp and the hostname into Shared Storage from inside the auction, and then writing a timestamp and the url-macro-asserted hostname into Shared Storage from the rendering environment, and using the Private Aggregation API to report on hostnames where you observe discrepancies. I get why that is less desirable than the in-the-moment detection that would be possible with 3, but it could let you find suspicious environments and decline to bid there (using pre-bid mechanisms!) in the future.

[dchristian-ias]

Thanks for the timely response and apologies for the delay on our end. Addressing your comments below:

1. We completely agree that pre-bid Brand Safety and Fraud Protection is the much cleaner approach. However, there are a few reasons why a post-bid check is still necessary for Verification Vendors:

   • Trust But Verify: The ORTB chain is pretty insecure. The top level url provided by SSPs -> DSPs pre-bid can’t always be trusted (can be spoofed), hence the need for an additional post-bid check to verify that the ad should be rendered is still needed.
   • Signal Integrity: As you mentioned, on the client side we are able to collect additional, more trustworthy signals, making the post-bid Brand Safety and Fraud Protection a more robust solution.
   • Integration Gaps: Not all DSPs that our Advertisers run on support a pre-bid Brand Safety and Fraud Protection mechanism. By providing this check post-bid, we can ensure that our clients are 100% covered.

   Given the above, Verification Vendors will need to continue to support both Pre-Bid and Post-Bid Brand Safety and Fraud Protection in order to provide our clients with full protection.

2. This makes sense. Would Chrome ever consider providing topWindowHostname inside Fenced Frames the same way it does for DSPs/SSPs inside the generateBid and scoreAd methods, respectively? This additional signal along with the check suggested (in bullet 3) would further help us identify fraudulent impressions.

3. This would be a welcomed addition and would improve the trustworthiness of the top level url provided by SSPs.

   With this approach, however, there is still a gap in the case the SSP decides not to populate the top level url macro. This is somewhat common, and would leave us with nothing to query. In the current state of Fenced Frames, we’d have no ancestor origins, nor top level url macro to collect.

   Would the Chrome team ever be open to providing a carve out for certified Verification Vendors, giving them access to the top level url and other needed signals to determine post-bid Fraud and Brand Safety to Advertisers?

4. This is an interesting approach. We are still working on our Pre-Bid Brand Safety / Fraud Protection offering for integration with PAAPI. Will reach back out with any additional questions here.

Thanks again.

[michaelkleber]

Providing topWindowHostname inside Fenced Frames would be a degradation of their privacy properties. Once we make some information available inside the rendering environment, there is no sense in which we can pick and choose which parties inside that environment can get ahold of it.

Any sort of exceptional carve-out for specific use cases would need to be more careful with data stewardship. The Privacy Sandbox approach to this would be something like a separate network request that goes to a server running inside a TEE.

[dchristian-ias]

The Privacy Sandbox approach to this would be something like a separate network request that goes to a server running inside a TEE.

Thanks. Just to clarify context, for the network request made to the server running inside a TEE, are you speaking to a network request originating from a Fenced Frame (a request made from our script to one of our servers running in a TEE), or are you speaking to a request made from a worklet during bidding time?

[michaelkleber]

Since we don't have a hook for this kind of thing right now, we'd need to start by understanding enough about the structure of your integration into the auction to figure out what sorts of solutions were viable. Something happening at bidding time is certainly more akin to the existing PA design, but I think we have wide latitude to figure out a design that can address this need.