JensenPaul
commented
6 days ago 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().
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: