Ibis

From Bitnami MediaWiki
Revision as of 17:41, 17 October 2021 by Jkoran (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The goal of Google's Interest-group Bid Integrity Support (Ibis) is to prevent malicious actor from manipulating the inputs into the local ad auction that occurs in Fledge/Turtledove. Ibis allows a marketer to encode a cap the price for an interest-based ad to limit the financial risk associated with such malicious manipulation.

Ibis adopts Google’s Privacy Sandbox goal of disintermediating publishers from the marketers that fund their digital properties.

Overview

Ibis identifies that when either publishers or marketers are disintermediated from the auction they cannot audit the malicious manipulation of the pricing that can occur. "Execution locally introduces the likelihood of manipulating the results of this process, or even simulating a fake TURTLEDOVE-style auction altogether."[1]

Ibis acknowledges that browsers cannot be trusted either by publishers or marketers. "This [malicious manipulation] can occur in real browsers or in simulated browsers."[2] Among the manipulations specifically identified by Ibis are:

  1. Setting second price auctions to "an arbitrarily high value to financially benefit a publisher, resulting in advertisers and DSPs paying high costs for low-value impressions"
  2. Manufacturing "impressions that were not shown to real users"
  3. Biased "auction logic and inputs themselves could potentially be manipulated to change the auction outcome" in violation of the duty to the publisher or marketer that the auction would be fair
  4. Self-preferencing actions to "prevent a competitor’s ad from being shown or to increase the probability of a preferred ad to be shown instead."[3]

Ibis provides a publisher trusted server to compare the winning auction value to the marketers' previously expressed maximum price. "During the impression notification, the encoded maximum bid price as well as the actual winning bid price can be sent back to the SSP or the aggregate reporting service. The winning bid price can then be validated for use in billing and reporting using the DSP-specified range."[4]

By comparing the actual winning bid price to the encoded max price of an interest-based ad, the system can detect if bid exceeds the marketer's max price.

Impact

Ibis acknowledges that even setting max prices does not safeguard publishers or marketers from a browser's malicious activity. "Will bid price constraints fully ensure on-device bid integrity? Unfortunately not. The proposed maximum bid price constraint approach will not be able to completely prevent bid manipulation."[5] The focus of Ibis is merely to limit the risk to marketers by having a cap on their bid price. However, marketers already bid their max price in both first and second price auctions. Thus it is unclear how Ibis actually mitigates any risk to buyers at all.

The key risk to marketers that Ibis highlights is that marketers may be interested in engaging the "right" audience based on interest-based signals but end up delivering their ad in a "low-value" context, which is the wrong place or time to be engaging that audience. By reducing the price marketers would pay to account for this risk, will unfortunately further negatively impact publisher revenues.

As with other Privacy Sandbox proposals that migrate B2B processing to the client, the incremental storage and processing cost for these auctions must be borne by consumers. This may degrade user experience or drain their mobile batteries.

Open Questions

  • What is the impact on web experiences given many client devices do not have the same processing power of the servers that currently select which content to render?
  • How does this solution actually reduce buyer risk?

See Also

References