Privacy Issues with the Existing Auction Nonce Implementation

[IanAtGoogle]

Auction Nonce is a protection within Additional Bids to prevent sellers from replaying buyers’ bids. The intent of an auction nonce is to provide a unique and non-repeatable key for each component auction which must be propagated to all buyers, so that buyers can include the nonce in signed Additional Bids. However, the current implementation for auction nonces introduces privacy risks that are avoidable.

As auction nonces are generated using browser JavaScript APIs, any component auction’s nonce can potentially be learned by any party running code on the publisher page (for example, through monkey-patching navigator.createAuctionNonce).

Today, publishers and SSPs can exercise control over the presence of identifiers (such as a site first-party cookie or a session ID) and other privacy-impacting signals that they send to buyers. Different sellers may have different privacy policies and controls available to publishers and end users. Auction nonce may potentially allow buyers to bypass those seller-provided controls and combine disjoint data across bid requests from the same browser in a way that is not necessarily possible today without relying on other identifiers (i.e. cookie-based). This joining of disjoint bid request data can be a privacy risk even after the auction has taken place.

Additionally, even when only a single seller is considered, the current auction nonce implementation poses a privacy risk due to the sequential nature of auction nonces generated within a given page session – effectively creating a session ID that sellers cannot control.

Additional Bids functionality should not require publishers and/or SSPs to reason about whether and when incremental privacy risks might arise. We propose two potential solutions that achieve the intended goal of an auction nonce (to prevent the replaying of buyers’ bids) without creating new privacy risks.

Proposal 1: Auction nonce = hash(browser nonce + seller-defined nonce).
We suggest the following mechanism that adds a seller-specified, server-side generated component to the browser generated nonce to create the final auction nonce.

1: Browser nonce is generated on-device through the existing browser API mechanism.
2: Browser nonce is included in the runAdAuction call and sent to the seller's contextual server.
3: In the seller contextual ad server, the seller generates a random seller nonce for each buyer and computes:
auction nonce = hash(browser nonce + random seller nonce) using a well-known hash function.
4: Seller sends the auction nonce to the buyer who includes it in their signed Additional Bid.
5: Seller returns bids to Chrome with both nonces via header:
Ad-Auction-Additional-Bid: <browser nonce>:<seller nonce>:<base64-encoding of the signed Additional Bid>
6: Chrome uses browser nonce to assign Additional Bids to auctions and verifies the auction nonce by combining the browser nonce and seller nonce.

Proposal 2: Allow auction nonce to be buyer-generated and provide a reporting mechanism for detecting the replay of bids.
In this proposal, each buyer specifies their own nonces and includes that nonce in their own Additional Bid. Subsequently, Chrome could let buyers access that nonce at reportWin time. While an event-level reporting mechanism is available, it's obvious how to detect potential seller Additional Bid replay from impressions with the same auction nonce. When aggregated reporting becomes required, Chrome could support an approximate count distinct operation to compare unique reported bid IDs to the number of impression events – which should be equal assuming Additional Bids are not replayed.

The browser would associate Additional Bids with a given component auction using the existing ad slot mechanism for directFromSellerSignals:
Ad-Auction-Additional-Bid: <ad slot name>:<base64-encoding of the signed Additional Bid>

[JensenPaul]

Your “Proposal 1” solution sounds reasonable, safe, and appears to address the privacy concerns raised in this issue without introducing additional privacy risks.  I think we should use SHA-256 for hashing so it’s preimage resistant to prevent replaying bids; so the auction nonce would be sha256(<browser-nonce-UUIDv4-string-representation><seller-nonce-UUIDv4-string-representation>).  Proposal 1 reuses the existing header and can be done in a backwards compatible way.  For consistency, I think we should require the seller nonce to be a version 4 UUID formatted like those coming from createAuctionNonce().

[orrb1]

Support for "seller nonce" as described above has been implemented, and is now available for testing on 50% of Chrome Canary/Dev channel traffic. It can also be manually enabled using the --enable-features=FledgeSellerNonce command line flag.

For more details, please see the explainer change in #1322 and the spec change in #1313.

Support can be feature detected by calling, from context of a web page:
navigator.protectedAudience && navigator.protectedAudience.queryFeatureSupport("sellerNonce")

[JensenPaul]

Support for "seller nonce" as described above is now available for testing on 50% of Chrome Canary/Dev and Beta channel traffic