Ad Pricing

[brodrigu]

Ad space pricing varies from publisher to publisher and the value of a given ad displayed on a given publisher will vary from buyer to buyer. Completely restricting any knowledge of the publisher for interest-group ads at ad request time will force complex pricing logic to be shifted to the browser.

This can greatly increase demands on the client system, possibly leading to degrading performance and user experience.

Buyer and Sellers often hold their pricing rules close to the vest. Sending pricing rules to the browser will also expose them publicly which could be problematic for both parties and lead to price manipulation.

Finally, it’s not clear from the proposal that if pricing were to be resolved client side there would be any way to report back what price was ultimately chosen.

[michaelkleber]

Ad space pricing varies from publisher to publisher and the value of a given ad displayed on a given publisher will vary from buyer to buyer. Completely restricting any knowledge of the publisher for interest-group ads at ad request time will force complex pricing logic to be shifted to the browser.

This can greatly increase demands on the client system, possibly leading to degrading performance and user experience.

You're entirely correct that the browser will be doing new work when executing the bidding JS, and that we (browser folks) will need to pay attention to be sure that it doesn't degrade the performance of the rest of the page. The JS in question is a good candidate for running off the main thread, though, which gives us a lot of options to minimize any perf impact.

Buyer and Sellers often hold their pricing rules close to the vest. Sending pricing rules to the browser will also expose them publicly which could be problematic for both parties and lead to price manipulation.

Note that the bidding function takes as input a variety of signals that came from the buyer's server (as part of both the 1p-and-contextual and interest-group ad responses). The meaning of those signals doesn't need to be shared with anyone. Of course it would be possible to send the server lots of ad requests and watch the signals that come back to try to learn what they mean... but by the same token, you could mount that kind of attack today and watch the ad prices that come back.

Finally, it’s not clear from the proposal that if pricing were to be resolved client side there would be any way to report back what price was ultimately chosen.

I don't think we can report the exact price back on an event-by-event basis, since the bidding function knows both the interest group and the context, and could be encoding some information about them in the bid. But the winning price could be made available to the Aggregate Reporting API (work in progress!) —a privacy-safe way that we can give access to values aggregated across a group of people, when learning the value for any specific person is inappropriate. The explainer section Frequency Capping, Budgets, Metrics, and Reporting talks about this a bit more.

[brodrigu]

You're entirely correct that the browser will be doing new work when executing the bidding JS, and that we (browser folks) will need to pay attention to be sure that it doesn't degrade the performance of the rest of the page.

Performance isn't only the responsibility of the browser folks, if so you'd have a lot to answer for. : )

the bidding function takes as input a variety of signals ... the meaning of those signals doesn't need to be shared with anyone

I know in another discussion there was talk of sending responses from multiple DSPs back to the page in the 1p-and-contextual request to be passed to the interest-group ads for decisioning. I don't find this feasible as it adds another multiplier to the amount of data and processing on the client which if it wasn't problematic up to this point, would certainly push it over the edge. Degrading publisher page performance is a serious concern even for us non-browser-folks.

That being said, the meaning of any provided signals would need to be clear and coordinated between the DSP and SSP, at minimum, so the appropriate ad matching could occur. It may be possible for the SSP or the exchange, to act as a broker and obfuscate these details but there would be plenty of motivation to decipher them and I don't think SSPs could provide any guarantee the data would be secured.

[michaelkleber]

Per our discussion over in #12, I think it's still an open question whether DSPs and SSPs would need to coordinate on signal meaning. But you're right that this in-the-browser auction gives the SSP a new opportunity to observe their partner DSPs' behavior.

It seems feasible to give DSPs additional protection here, at some complexity cost.

In the Trust Tokens explainer, we included an extension on Trust-Bound Keypair and Request Signing. This involves the browser signing outbound requests with a private key, and including the signature and the corresponding public key in a header. Any server in possession of that header is able to cryptographically verify that the request and signature genuinely came from someone trusted by the Trust Token issuer.

Once some server has the browser-created public key, the server could use that key to encrypt a message that it wants to send back to the browser as a response. Intermediaries (here the SSP that you're worried about) would still be able to drop the DSP's encrypted message, of course. But the encryption would prevent the SSP from reading those signals.

Since the browser's public key is known to everyone, this wouldn't prevent a malicious SSP from forging a message with fake signals of its own devising. But the per-reader-domain public key that already shows up in the current explainer could similarly be used by the DSP to sign its signals, to make the communications channel robust against both eavesdropping and impersonation.

I don't know whether or not this complexity is worth the benefit — it all depends on the threat model, where the threat being discussed now isn't about people's privacy, it's about business relations between different ad tech players. But I think this shows that the browser could offer an appropriate communications channel with the DSPs, if that's what the industry wants.

[JensenPaul]

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Protected Audience (formerly known as FLEDGE) proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.