Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Ship: Protected Audience: Auction Nonce Hardening

296 views
Skip to first unread message

Orr Bernstein

unread,
Nov 25, 2024, 9:15:16 AM11/25/24
to blink-dev, paulj...@chromium.org, cara...@chromium.org

Contact emails

or...@google.com, paulj...@chromium.org, cara...@chromium.org


Explainer

https://github.com/WICG/turtledove/pull/1322


Specification

https://github.com/WICG/turtledove/pull/1313


Summary

Additional bids are a feature of the Protected Audience auction that provide buyers with a way to include server-constructed contextual bids in the auction, which allows negative targeting of those bids. We've identified a potential privacy risk with the current implementation, as well as a potential solution that addresses that risk. Additional bids come from buyers, but are transported to the auction by the auction's seller. To prevent replay of additional bids, additional bids rely on an auction nonce — a unique number created by and used by the browser to uniquely identify that auction. However, this introduces a privacy risk, in that all buyers see the same auction nonce, and could use that auction nonce as a key to join distinct bid requests for an auction. This proposal allows sellers to introduce an additional nonce that gets combined with the browser-provided one so that buyers see different combined nonces across bid requests, preventing the joining of bid requests. The combined nonce is generated through a one-way hash (SHA-256) to prevent the construction of a combined nonce that matches a previous combined nonce, which could otherwise be used to facilitate the replay of an additional bid.


Blink component

Blink>InterestGroups


TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Completed for Protected Audience, resolved unsatisfied.


Risks


Interoperability and Compatibility

Optional new functionality that does not break existing use.


Gecko & WebKit: For Protected Audiences in general - Negative from Mozilla. No signal from Webkit.


Edge: Edge is running an Origin Trial of the Ad Selection API which shares a Web API and services protocol with Protected Audience.


Web developers: Requested by ad tech in GitHub issue #1198.


Debuggability

Ad-Auction-Additional-Bid response headers are visible in the DevTools Network tab, and each can be trivially decoded into an auction nonce, a seller nonce, and a base-64 encoded signed additional bid. Errors encountered while decoding and parsing the signed additional bid are presented in the DevTools console. Additional bids are debuggable via DevTools debugging of Protected Audience scoring scripts.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

It will be supported on all platforms that support Protected Audience, so all but WebView.


Is this feature fully tested by web-platform-tests?

Yes 


Flag name on chrome://flags

None


Finch feature name

FledgeSellerNonce


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M132.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5081571282124800


This intent message was generated by Chrome Platform Status.

Vladimir Levin

unread,
Dec 3, 2024, 9:03:22 PM12/3/24
to Orr Bernstein, blink-dev, paulj...@chromium.org, cara...@chromium.org
On Mon, Nov 25, 2024 at 9:15 AM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:

Contact emails

or...@google.com, paulj...@chromium.org, cara...@chromium.org


Explainer

https://github.com/WICG/turtledove/pull/1322


Specification

https://github.com/WICG/turtledove/pull/1313


Summary

Additional bids are a feature of the Protected Audience auction that provide buyers with a way to include server-constructed contextual bids in the auction, which allows negative targeting of those bids. We've identified a potential privacy risk with the current implementation, as well as a potential solution that addresses that risk. Additional bids come from buyers, but are transported to the auction by the auction's seller. To prevent replay of additional bids, additional bids rely on an auction nonce — a unique number created by and used by the browser to uniquely identify that auction. However, this introduces a privacy risk, in that all buyers see the same auction nonce, and could use that auction nonce as a key to join distinct bid requests for an auction. This proposal allows sellers to introduce an additional nonce that gets combined with the browser-provided one so that buyers see different combined nonces across bid requests, preventing the joining of bid requests. The combined nonce is generated through a one-way hash (SHA-256) to prevent the construction of a combined nonce that matches a previous combined nonce, which could otherwise be used to facilitate the replay of an additional bid.


According to the explainer, the auction nonce (generated by the browser, and given to the seller (?)) is combined with a seller generated nonce to generate a bid nonce that buyers see. That's to make sure that buyers can't use the auction nonce to figure out other bids that are happening for the same auction, right? Then the bid nonce is returned back to the seller. I presume this is to identify which auction the bid is for? What I don't understand is that the bid nonce is then returned to the browser, but the browser only knows the auction nonce so wouldn't it have no way to match that with an auction because it doesn't know seller generated nonce for this bid?

Another unrelated question, does this have any separate implications for Trusted Execution Environments? Specifically, does this apply to both or only to "local" auctions?

Thanks,
Vlad
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANHsO6stZ5OtCo3xy127pz_9w7V_NJjx2ZvfzP%2BnJowRC8cmzg%40mail.gmail.com.

Caleb Raitto

unread,
Dec 18, 2024, 12:19:46 PM12/18/24
to blink-dev, Vladimir Levin, blink-dev, paulj...@chromium.org, Caleb Raitto, or...@google.com
Responses inline

On Tuesday, December 3, 2024 at 9:03:22 PM UTC-5 Vladimir Levin wrote:
On Mon, Nov 25, 2024 at 9:15 AM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:
Contact emails

or...@google.com, paulj...@chromium.org, cara...@chromium.org


Explainer

https://github.com/WICG/turtledove/pull/1322


Specification

https://github.com/WICG/turtledove/pull/1313


Summary

Additional bids are a feature of the Protected Audience auction that provide buyers with a way to include server-constructed contextual bids in the auction, which allows negative targeting of those bids. We've identified a potential privacy risk with the current implementation, as well as a potential solution that addresses that risk. Additional bids come from buyers, but are transported to the auction by the auction's seller. To prevent replay of additional bids, additional bids rely on an auction nonce — a unique number created by and used by the browser to uniquely identify that auction. However, this introduces a privacy risk, in that all buyers see the same auction nonce, and could use that auction nonce as a key to join distinct bid requests for an auction. This proposal allows sellers to introduce an additional nonce that gets combined with the browser-provided one so that buyers see different combined nonces across bid requests, preventing the joining of bid requests. The combined nonce is generated through a one-way hash (SHA-256) to prevent the construction of a combined nonce that matches a previous combined nonce, which could otherwise be used to facilitate the replay of an additional bid.


According to the explainer, the auction nonce (generated by the browser, and given to the seller (?)) is combined with a seller generated nonce to generate a bid nonce that

Correct - the seller does receive the auction nonce. When constructing the auction config, the seller creates an auction nonce using the existing navigator.createAuctionNonce() function. The seller can then send this auction nonce as part of the request to their contextual server.
 
buyers see. That's to make sure that buyers can't use the auction nonce to figure out other bids that are happening for the same auction, right?

Correct - with this change, the auction nonce is no longer given to bidders, so that it can not be used to join bid-requests together server-side.
 
Then the bid nonce is returned back to the seller. I presume this is to identify which auction the bid is for?

Right -- we want to avoid replay attacks, where a bid is entered into an auction for which it wasn’t intended. This is why the original auction nonce mechanism was created, and this new design should preserve this replay attack protection.
 
What I don't understand is that the bid nonce is then returned to the browser, but the browser only knows the auction nonce so wouldn't it have no way to match that with an auction because it doesn't know seller generated nonce for this bid?

The seller nonce is also returned to the browser, via the Ad-Auction-Additional-Bid response header. The browser can then calculate the bid nonce from the auction nonce and the seller nonce in the same way that the seller did to send the bid nonce to the buyer. 
 

Another unrelated question, does this have any separate implications for Trusted Execution Environments? Specifically, does this apply to both or only to "local" auctions?

Currently, additional bids aren’t supported for auctions conducted on Bidding and Auction (B&A) services, although such support could be added in the future, under a different I2S.
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Chris Harrelson

unread,
Jan 8, 2025, 11:06:21 AMJan 8
to Caleb Raitto, blink-dev, Vladimir Levin, paulj...@chromium.org, or...@google.com
LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75fe8dee-bd6f-4515-b77d-4ceccda28cban%40chromium.org.

Mike Taylor

unread,
Jan 8, 2025, 2:38:07 PMJan 8
to Chris Harrelson, Caleb Raitto, blink-dev, Vladimir Levin, paulj...@chromium.org, or...@google.com

Yoav Weiss (@Shopify)

unread,
Jan 9, 2025, 4:53:25 AMJan 9
to Mike Taylor, Chris Harrelson, Caleb Raitto, blink-dev, Vladimir Levin, paulj...@chromium.org, or...@google.com
What happens if sellers don't provide nonces of their own? Do we continue to send the auction nonces that can be used as an id? If so, are there plans to deprecate it? If we don't, what's the compat risk?

Caleb Raitto

unread,
Jan 13, 2025, 3:18:33 PMJan 13
to blink-dev, Yoav Weiss, Chris Harrelson, Caleb Raitto, blink-dev, Vladimir Levin, paulj...@chromium.org, or...@google.com, Mike Taylor

To clarify, the browser doesn’t actively send the auction nonce.  The browser provides an API, navigator.createAuctionNonce(), where sellers can request the auction nonce.


This proposal introduces a new mechanism where sellers provide nonces, but does not deprecate the old behavior.  We could consider deprecating the old behavior once this new behavior is adopted.


-Caleb
LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss (@Shopify)

unread,
Jan 14, 2025, 4:00:18 AMJan 14
to Caleb Raitto, blink-dev, Chris Harrelson, Vladimir Levin, paulj...@chromium.org, or...@google.com, Mike Taylor
OK, so this doesn't solve the potential privacy issue, but pushes an alternative mechanism that would enable us to resolve it in the future. Got it!

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss (@Shopify)

unread,
Jan 15, 2025, 10:00:29 AMJan 15
to blink-dev, Yoav Weiss, blink-dev, Chris Harrelson, Vladimir Levin, paulj...@chromium.org, Orr Bernstein, Mike Taylor, Caleb Raitto
LGTM3

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages