LGTM1 On Wed, Dec 18, 2024 at 9:19 AM Caleb Raitto <carai...@chromium.org> wrote:
> 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 < > blink-dev@chromium.org> wrote: > > Contact emails > > o...@google.com, pauljen...@chromium.org, carai...@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 > <https://github.com/WICG/turtledove/blob/main/FLEDGE.md#63-http-response-headers:~:text=The%20structure%20of,signed%20additional%20bid%3E>. > The browser can then calculate > <https://github.com/WICG/turtledove/blob/main/FLEDGE.md#61-auction-and-bid-nonces:~:text=The%20seller%20must%20combine,as%20a%20base64%20string.> > 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. > > > > Thanks, > Vlad > > > > Blink component > > Blink>InterestGroups > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups> > > > 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 > <https://github.com/mozilla/standards-positions/issues/770#issuecomment-2432124085>. > No signal from Webkit > <https://github.com/WebKit/standards-positions/issues/158#issuecomment-2432121278> > . > > > Edge: Edge is running an Origin Trial of the Ad Selection API > <https://github.com/WICG/privacy-preserving-ads/blob/main/README.md> > which shares a Web API and services protocol with Protected Audience. > > > Web developers: Requested by ad tech in GitHub issue #1198 > <https://github.com/WICG/turtledove/issues/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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > Yes <https://chromium-review.googlesource.com/c/chromium/src/+/5979020> > > > 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 > <https://chromestatus.com/>. > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANHsO6stZ5OtCo3xy127pz_9w7V_NJjx2ZvfzP%2BnJowRC8cmzg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75fe8dee-bd6f-4515-b77d-4ceccda28cban%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw88gzSNtR_JJ15xU%2B1S45R5jEw8DQJ8SN%2BuE88zvk-0%3DQ%40mail.gmail.com.
