Intent to Ship: Protected Audience: cross-origin trusted signals fetches
Paul Jensen
Contact emails
Explainer
https://github.com/WICG/turtledove/pull/1156
Specification
https://github.com/WICG/turtledove/pull/1197
Side note: there are two related clarification spec PRs (1, 2) that are soon to land but our spec mentor is fine with the spec in its current state, because the new PRs are queued up, even if they don't land right away. The serious meat in the main PR is in place, and any gaps in interoperability are right behind.
Summary
This feature allows the Protected Audience (PA) API to fetch real-time bidding and scoring signals from origins other than the origin of the buyer and seller's scripts. This is done by enabling CORS on these requests and some additional checks and requirements, and changes to prevent misuse. We have heard that this is a critical feature request because dynamic server-generated responses for the real-time bidding and scoring signals are likely to not be served from the same servers as static resources like the bidding and scoring scripts. Furthermore, in the future when the real-time bidding and scoring signals requests will be required to be served from TEEs, they’re even more likely to be served from different servers.
We’re also including some ergonomic improvements to our PA feature detection API that make it easier to query PA feature support without modifying on-page JavaScript.
Blink component
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
Feature represents optional new behavior that shouldn’t break existing usage.
Gecko & WebKit: No signal on parent proposal, Protected Audience. Asked in the Mozilla forum here, and in the Webkit forum here.
Edge: Edge has announced plans to support the Ad Selection API which shares much of its API surface with Protected Audience.
Web developers: Requested by 5+ companies (including Microsoft Ads) in multiple GitHub issues: 1, 2, 3.
Debuggability
Protected Audience trusted signals requests show up in the DevTools Network pane.
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?
Flag name on chrome://flags
None
Finch feature name
FledgePermitCrossOriginTrustedSignals
Requires code in //chrome?
False
Estimated milestones
Shipping on desktop and Android in M127.
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5861201518264320
This intent message was generated by Chrome Platform Status.
Maksim Orlovich
--
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 [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrkWa-a9HmaqoSdkVhQ8YbMpY1Q-AvJtQLsyCcAfN8jBHQ%40mail.gmail.com.
Yoav Weiss (@Shopify)
Note: https://github.com/WICG/turtledove/pull/1230 is an updated link for the second spec clarification pull requests, and the first one of the two has landed.On Fri, Jul 19, 2024 at 4:40 PM Paul Jensen <[email protected]> wrote:Contact emails
Explainer
https://github.com/WICG/turtledove/pull/1156
Specification
https://github.com/WICG/turtledove/pull/1197
Side note: there are two related clarification spec PRs (1, 2) that are soon to land but our spec mentor is fine with the spec in its current state, because the new PRs are queued up, even if they don't land right away. The serious meat in the main PR is in place, and any gaps in interoperability are right behind.
Summary
This feature allows the Protected Audience (PA) API to fetch real-time bidding and scoring signals from origins other than the origin of the buyer and seller's scripts. This is done by enabling CORS on these requests and some additional checks and requirements, and changes to prevent misuse.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHRWggT6TM2-RhO%3D5G6fZ2CdaiWLJkx-a1XFOSzwnOBR4XuV%2BA%40mail.gmail.com.
Paul Jensen
On Mon, Jul 22, 2024 at 5:26 PM 'Maksim Orlovich' via blink-dev <[email protected]> wrote:Note: https://github.com/WICG/turtledove/pull/1230 is an updated link for the second spec clarification pull requests, and the first one of the two has landed.On Fri, Jul 19, 2024 at 4:40 PM Paul Jensen <[email protected]> wrote:SummaryThis feature allows the Protected Audience (PA) API to fetch real-time bidding and scoring signals from origins other than the origin of the buyer and seller's scripts. This is done by enabling CORS on these requests and some additional checks and requirements, and changes to prevent misuse.
Can you expand on the "changes to prevent misuse" part?What misuse are we concerned with? What have we done to avoid it?
Previous to this proposal, the trusted signals were required to come from the same origin as the bidding or scoring script that processed them, and the script could safely assume that the signals it received were from its same origin. With this new ability to fetch them from another origin we wanted to avoid a couple forms of misuse:
unintentional/accidental misconfiguration where the trusted signals origin (specified in the interest group or auction configuration) could now be a different origin but the script processing these signals might not be updated to understand this or process signals from another origin, or
intentional/malicious misconfiguration where someone might have changed the origin of the trusted signals unbeknownst to the script processing them. This isn’t possible for trusted bidding signals as the interest group (where the trusted bidding signals URL is specified) is only settable from same-origin contexts. Auction configurations (where the trusted scoring signals URL is specified) don’t have the same same-origin setting requirements, but this is why this proposal requires the scoring script to include the Ad-Auction-Allow-Trusted-Scoring-Signals-From response header which lists allowed origins for the trusted scoring signals. Misconfiguration here could look like a scoring script allowing two trusted scoring signals origins, and someone switching between these allowed origins unexpectedly.
To prevent these misconfigurations, we changed how the trusted signals are passed to the scripts: they are passed in a new parameter so as not to be confused with the previously always-same-origin signals parameter, and this new parameter is a map from the origin of the signals to the signals themselves. This was discussed as risk #2 in my GitHub post.
The Ad-Auction-Allow-Trusted-Scoring-Signals-From header also prevents the trusted scoring signals request from being sent to unexpected origins.
Yoav Weiss (@Shopify)
On Friday, July 26, 2024 at 5:28:22 AM UTC-4 Yoav Weiss wrote:On Mon, Jul 22, 2024 at 5:26 PM 'Maksim Orlovich' via blink-dev <[email protected]> wrote:Note: https://github.com/WICG/turtledove/pull/1230 is an updated link for the second spec clarification pull requests, and the first one of the two has landed.On Fri, Jul 19, 2024 at 4:40 PM Paul Jensen <[email protected]> wrote:SummaryThis feature allows the Protected Audience (PA) API to fetch real-time bidding and scoring signals from origins other than the origin of the buyer and seller's scripts. This is done by enabling CORS on these requests and some additional checks and requirements, and changes to prevent misuse.
Can you expand on the "changes to prevent misuse" part?What misuse are we concerned with? What have we done to avoid it?Previous to this proposal, the trusted signals were required to come from the same origin as the bidding or scoring script that processed them, and the script could safely assume that the signals it received were from its same origin. With this new ability to fetch them from another origin we wanted to avoid a couple forms of misuse:
unintentional/accidental misconfiguration where the trusted signals origin (specified in the interest group or auction configuration) could now be a different origin but the script processing these signals might not be updated to understand this or process signals from another origin, or
intentional/malicious misconfiguration where someone might have changed the origin of the trusted signals unbeknownst to the script processing them. This isn’t possible for trusted bidding signals as the interest group (where the trusted bidding signals URL is specified) is only settable from same-origin contexts.
Chris Harrelson
--
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 [email protected].
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3759194-8de5-45d1-9c96-6c4421194337n%40chromium.org.
Mike Taylor
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw84wWViN6yzFAYjTA3BVp%3DSsRxo%2BHg3%2BBdAHT2Z4F4irQ%40mail.gmail.com.
Paul Jensen
On Wednesday, July 31, 2024 at 6:38:43 PM UTC+2 Paul Jensen wrote:Previous to this proposal, the trusted signals were required to come from the same origin as the bidding or scoring script that processed them, and the script could safely assume that the signals it received were from its same origin. With this new ability to fetch them from another origin we wanted to avoid a couple forms of misuse:
unintentional/accidental misconfiguration where the trusted signals origin (specified in the interest group or auction configuration) could now be a different origin but the script processing these signals might not be updated to understand this or process signals from another origin, or
intentional/malicious misconfiguration where someone might have changed the origin of the trusted signals unbeknownst to the script processing them. This isn’t possible for trusted bidding signals as the interest group (where the trusted bidding signals URL is specified) is only settable from same-origin contexts.
That last part is using AsyncTask? Is that well-defined in the PR? I'm not sure we have a strict concept of "context" in the platform today.TaskAttribution took a stab at that and AsyncContext is another, but I guess that making that implementation-defined would work as well for now.