From 825afc4a47a650d8335bb6cc94c7947bb9ae1453 Mon Sep 17 00:00:00 2001 From: David Dabbs Date: Tue, 11 Jun 2024 14:33:03 -0500 Subject: [PATCH 01/13] Update FLEDGE.md (deprecatedRenderURLReplacements dict typo) (#1189) Update `deprecatedRenderURLReplacements` dict to what `runAdAuction()` accepts. --- FLEDGE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FLEDGE.md b/FLEDGE.md index 588563e55..fea63b471 100644 --- a/FLEDGE.md +++ b/FLEDGE.md @@ -383,8 +383,8 @@ const myAuctionConfig = { 'perBuyerMultiBidLimits': {'https://example.com': 10, '*': 5}, 'sellerCurrency:' : 'CAD', 'reportingTimeout' : 200, - 'deprecatedRenderURLReplacements':{{'${SELLER}':'exampleSSP'}, - {'%%SELLER_ALT%%':'exampleSSP'}}, + 'deprecatedRenderURLReplacements':{'${SELLER}':'exampleSSP', + '%%SELLER_ALT%%':'exampleSSP'}, 'componentAuctions': [ {'seller': 'https://www.some-other-ssp.com', 'decisionLogicURL': ..., From e615700c82196c8f83772b94adc2e15ddb616f03 Mon Sep 17 00:00:00 2001 From: Michael Kleber Date: Wed, 12 Jun 2024 09:49:57 -0400 Subject: [PATCH 02/13] Create 2024-06-05-FLEDGE-call-minutes.md --- meetings/2024-06-05-FLEDGE-call-minutes.md | 253 +++++++++++++++++++++ 1 file changed, 253 insertions(+) create mode 100644 meetings/2024-06-05-FLEDGE-call-minutes.md diff --git a/meetings/2024-06-05-FLEDGE-call-minutes.md b/meetings/2024-06-05-FLEDGE-call-minutes.md new file mode 100644 index 000000000..0e9d99543 --- /dev/null +++ b/meetings/2024-06-05-FLEDGE-call-minutes.md @@ -0,0 +1,253 @@ +# Protected Audience WICG Calls: Agenda & Notes + +Calls take place on most Wednesdays, at 11am US Eastern time; check [#88](https://github.com/WICG/turtledove/issues/88) for exceptions. + +That's 8am California = 5pm Paris time = 3pm UTC (during summer) + +This notes doc will be editable during the meeting — if you can only comment, hit reload + +Notes from past calls are all on GitHub [in this directory](https://github.com/WICG/turtledove/tree/main/meetings). + + +# Next video-call meeting: Wednesday June 5, 2024 + +To be added to a Google Calendar invitation for this meeting, join the Google Group https://groups.google.com/a/chromium.org/g/protected-audience-api-meetings/ + + +## Attendees: please sign yourself in! + + + +1. Jason Lydon (FT) +2. Paul Jensen (Google Privacy Sandbox) +3. Don Marti (Raptive) +4. Brian May (Dstillery) +5. Patrick Mccann (Raptive) +6. David Dabbs (Epsilon) +7. Garrett McGrath (Magnite) +8. Matt Menke (Google Chrome) +9. Sven May (Google Privacy Sandbox) +10. Matt Kendall (Index Exchange) +11. Roni Gordon (Index Exchange) +12. Isaac Foster (MSFT Ads) +13. Laurentiu Badea (OpenX) +14. Kenneth Kharma (OpenX) +15. Jacob Goldman (Google Ad Manager) +16. Aymeric Le Corre (Lucead) +17. Alexandre Nderagakura (Independent / Consulting) +18. Harshad Mane (PubMatic) +19. Jeroune Rhodes- Google Privacy Sandbox +20. Sid Sahoo (Google Chrome) +21. Alonso Velasquez (Google Privacy Sandbox) +22. Orr Bernstein (Google Privacy Sandbox) +23. Fabian Höring (Criteo) +24. Sathish Manickam (Google Privacy Sandbox) +25. Wendell Baker (Yahoo) +26. Alex Peckham (Flashtalking) +27. Abishai (Google Privacy Sandbox) +28. Victor Pena (Chrome) +29. Russ Hamilton (Google Privacy Sandbox) +30. Laura Morinigo (Samsung) +31. Tal Bar Zvi (Taboola) +32. Guillaume Polaert (Pubstack) +33. Arthur Coleman (IDPrivacy/ThinkMedium) +34. Pawel Ruchaj (Audigent) +35. David Tam (Relay42) +36. Yanay Zimran (Start.IO) +37. Koji Ota(CyberAgent) +38. Maybelline Boon (Google Privacy Sandbox) + + +## Note taker: Orr Bernstein + + +# Agenda + + +## Process reminder: Join WICG + +If you want to participate in the call, please make sure you join the WICG: https://www.w3.org/community/wicg/ + +Contributions to this work are subject to W3C Community Contributor License Agreement (CLA) which can be found here: https://www.w3.org/community/about/process/cla/ + + +## Suggest agenda items here: + + + +* Isaac Foster: + * Brief revisit the “coarse information sharing” thing, we had talked about setting up time but never did, all got too busy…can even answer here + * Multi Tag Support via “Mixed Ranking”: (really, this + multi tag + bit leak discussion and how we can be creative) https://github.com/WICG/turtledove/issues/846 + * Optional decouple bidding/reporting function urls to allow smaller k tuple: https://github.com/WICG/turtledove/issues/679#issuecomment-1703973736 +* Tal Bar Zvi (instead of Omri Ariav for this meeting) + * Follow up on easing domain restrictions (https://github.com/WICG/turtledove/issues/956) + * (Roni) https://github.com/WICG/turtledove/pull/1156 resolves https://github.com/WICG/turtledove/issues/813 +* Warren Fernandes + * Follow up on the proposal to support an analytics entity (https://github.com/WICG/turtledove/issues/1115) +* Patrick McCann (_from Google Chat_) + * https://github.com/WICG/turtledove/pull/1156 + * Can we expect a reasonable cap on the \* at:[ ](https://github.com/WICG/turtledove/pull/1156/file)for number of features returned in `queryFeatureSupport('\*')`? + + +# Announcements + +The Microsoft Edge folks are holding every-second-Thursday meetings at this same hour to discuss their very similar "Ad Selection API" work. See https://github.com/WICG/privacy-preserving-ads/issues/50 for logistics. + +**Join Privacy Sandbox Developer Webinar: Protected Audience API Reporting** + +The Google Privacy Sandbox team will be hosting our next series of webinars on the Protected Audience API. This is the fourth series of webinars covering the Protected Audience API and in this session, we will continue from the previous session and learn about reporting. The first **Americas friendly session** is happening on** June 25th 3-4 pm ET**. A second **EMEA friendly session** is happening **June 26th 12-1 pm GMT**. + +To join, please register below: + + +* AMER-friendly: [Register Here](https://rsvp.withgoogle.com/events/protected-audience-webinar-4-reporting2-amer) + + +* EMEA-friendly: [Register Here](https://rsvp.withgoogle.com/events/protected-audience-webinar-4-reporting2-emea) + + +# Notes + + +## Patch’y Updates When on Joining Origin: https://github.com/WICG/turtledove/issues/1162 + + + +* Isaac Foster + * Today, if you join an IG (ignoring cross-site) on example.com, you put in - among other things - an updateUrl and possibly ads and other things. Later, the updateUrl is called. UpdateUrl semantics are patchy - only updates keys you specify. Later on, the user comes back to the page - the code on page, because it doesn’t know what IGs have been registered, what their state is, rejoins the IG. Could make calls to a service for coordination, but would be nice if you could do patchy update instead of overwriting everything at IG join. + * Has come up in two contexts - internally, and talking with some folks about delegation scenarios. Broadly relevant. + * Proposal: leverage the joining origin. Allow patchy semantics joinAdInterestGroup if it’s joined from the same joining origin. Could rejoin an IG and then build from there. + * Intention is that this would only be applicable under the same joining origin, not suggesting we allow this across sites. +* Brian May + * You create an IG. Whatever state it’s in, you call an update server, which provides some updates to it. If you then create the IG and it calls the update server again, won’t it have everything it had? + * If all IGs could have unique state, very difficult to understand how to interact with an interest group - if IGs are not uniform across all expressions of them. +* Issac + * Are you referring to a distributed systems case where the IGs are kind of meant to be semantically the same across browsers, but they will definitely not be updated at the same point? +* Brian + * An IG is an entity shared across all browser instances in which it appears, hopefully has a common definition across all browsers. +* Paul Jensen + * Possible that an IG is different across different devices depending on when they were updated. +* Brian + * But if two IGs hit the update server at the same time, they should have the same understanding of what the IG is. +* Paul + * Could make your update server give back different results at different times. We’re not enforcing that it’s giving the same response every time. Could be adding ads to your IG as you go along. If an IG is updated at this time, and another at a later time, they could have different sets of ads. +* Brian + * Difficult to reason about what it is you’re interacting with if two IGs have the same name but very different ads. +* Isaac + * Problem of - can we effectively touch an IG on a page without changing features that require a call to the server - you prefer not to do that in some cases. In a multi-billion node distributed system, add a timestamp to make sure things are synced, but if you’re putting in something that’s meant to be synced in a more interesting way, that would be challenging. +* Paul + * If you break the original problem into two pieces, interacts with what Brian mentioned. a) extend the lifetime, and b) not lose all the ads that may have been downloaded during an update. + * If you look at (b), if you rejoin the IG, which deletes the ads, but then immediately call update, could get ads back, so they’re not lost. May run into rate limiting if we updated the IG recently. But the expiration date is a different problem, and the patchiness/partial updating is kind of a different problem. + * The thing we’re trying to preserve - one IG contains one site worth of data - and this can be broken when we don’t do these complete overwrites. I linked to a couple of GitHub comments where this is discussed. Could have one IG that’s joined from lots of different sites, and then it becomes a product of multiple sites. + * We’ve encountered this multiple times, and the solution we’ve come up with is - when IGs are joined from a different site, it’s often an error, and so it’s joined anew when joined from the second site. +* Isaac + * Without making a different call - different companies are going to setup different update strategies - modify the bidding signals or even the trusted signal URL - if you happened to join from different sites, then yes, it would go back to overwrite semantics. +* David Dabbs + * The use case you described is an IG that’s only going to be joined on an advertiser site. But can’t you set a CHIPS cookie, and so you don’t drop the IG with a second join? + * Lightweight, scaffolding at join time - mechanism to ensure that the updateURL gets called - already called the update URL and is ready to go. That proposal might provide some means to get what you want. +* Isaac + * Like the idea of not having to make the call. If it’s a matter of asking, please run the update if it hasn’t been run. Certainly could set something in cookie or local storage. +* Brian + * It occurred to me that the person creating the IG could call the update server and create the join based on what they got back from the update server; don’t need the browser to do it on their behalf. Once an IG is updated, we probably want to have a “don’t update this IG for a specific period of time”, so it’s not constantly being refreshed, either on purpose or by accident. If the semantics of an IG creation was to call the update server immediately. + * I would want to try to get the IGs to be as consistent as possible across these billion nodes; can’t treat the IG updated today the same as I would the IG updated yesterday. +* Isaac + * Setting local storage is fine. Having developers not need to do that - if you’re on a site, you’re navigating around - but having to make those calls on every page load instead of just being able to say, call this update unless you did so in the last two hours or whatever. +* Paul + * David - you’re right to point out that what Issac is asking for is something you could do today using first-party storage. Good that we’re asking for things that are asking for convenience. +* Roni Gordon + * In the interest of not trying to design it in real time, since I’m not a buyer, we have updateIfOlderThanTime, Brian has don’tUpdateIfOlderThanTime. What can be patched, what can’t be patched, and how do we do it we can leave to GitHub. +* Paul + * What we’re trying to prevent is that an IG contains data from multiple sites. Any update is OK because the updateURL comes from the original site. Priority vector is a little different because it’s not exposed; but in terms of joining and updating, what we’re trying to maintain is that it’s from one site. +* Brian + * Am interested in the concept of TTL. You don’t want the browser getting crowded. But do want IGs that are renewed as long as there’s a certain amount of activity related to them. Audience extension and other sorts of cross-site advertising without the cross-site data. +* Paul + * We have a 30 day TTL, and it can be extended by rejoining it, but not update. Need some kind of limit on the TTL and we need to prevent mechanisms that allow it to be updated. +* Isaac + * Have to drop for a different meeting. Thanks for the conversation. +* Paul + * Something like this could be possible as long as we have a mechanism for preventing it from accumulating state from multiple sites. Could have something like “updateOrDelete” - would delete the IG if it had been created from a different site. +* David + * Brian - to the points you’ve been making - the focus should be achieving a patchy update whether they have a conception of an IG that you do that has the IG being consistent - or whether the contents of the IG may be different based on what was on that first party site at join time. About a year ago, updateURL was removed from the k-anonymity calculus - which allows people to apply it in different ways. +* Paul + * To Brian’s comment - have to assume that if ads for campaigns are changing, the potential for different versions of the same IG on different devices is possible. Can’t have a perfectly distributed coherent DB across all devices. Signals like when it was updated or what version of it has been kept on that particular device could help. + + +## Follow up on easing domain restrictions (https://github.com/WICG/turtledove/issues/956) + + + +* Tal Bar Zvi (instead of Omri Ariav for this meeting) + * With Taboola, following up on question on a GitHub issue + * Owner domain - used both to download most static files - that contain GenerateBids, ScoreAd, reportWin, reportResult, and also downloading web assemblies. + * And then there’s trusted server - now BYOS - that has to use the same exact DNS name as the prefix, and this kind of server usually costs more because of the dynamic call. + * The first is static resource, the second is dynamic resource, and they have to have the same domain name. + * I know you addressed this subject recently in this issue that Roni created. Is this the same issue? +* Paul + * Yes, Roni filed #813. We talked about it on previous calls. It did boil down to that differentiation of resources in the interest group. Some static (CDN), some some more dynamic as you called them. Isaac mentioned a few calls ago that this was their motivation for asking on #813. + * We’ve been working on the solution for this. Pushed out the solution to Canary Chrome at 50% earlier this week. Should be on Chrome Dev Channel soonish maybe next week or something. + * Detectable with some feature detection mechanisms + * Should address the issue that #956 was asking about, where you might want to serve some things from static origin and other things from dynamic ones. + + +## https://github.com/WICG/turtledove/pull/1156 + + +## Can we expect a reasonable cap on the \* at:[ ](https://github.com/WICG/turtledove/pull/1156/file)for number of features returned in `queryFeatureSupport('\*')`? + + + +* Patrick McCann + * Speaking of feature detection - you guys plan to cap the number of features it returns, we’re just kind of worried about sending the whole thing over the wire. +* Paul + * We don’t plan to cap things. +* Patrick + * In a year, is it going to be 200-300 features? +* Paul + * Multiple ways we can address things. For example, could ignore things you already know about. In terms of keeping the list smaller and simpler, when we go about shipping these different features, we roll them out for testing on the early channels - canary, dev, beta, then stable some percentage, and then we turn them on by default. After that, all versions of Chrome will have them on supposedly forever. If you’re already getting the Chrome version, could omit those features that are enabled by default. Could only find out about experimental things that are enabled only for a fraction of traffic. +* Roni + * As of this version, these things are available. That’s not formally available either. If I can’t infer which versions are available - what can I figure out. +* Paul + * We do have the feature detection page in our repository. Put in links for the intent to ships (I2Ss), but could also put in links to the version of the CL that added it on by default. +* David + * Back in the dawn of time, the release notes were useful, but you guys don’t do that anymore. + + +## (Back to) Follow up on easing domain restrictions + + + +* David + * Separating the reporting from the bidding logic. Now that we can separate host, can we take that out of the calculation? +* Paul + * One of Isaac’s topics +* David + * Can address another time. +* Paul + * Isaac was looking at something like - many versions of a bidding script with fewer versions of reporting script - might be easier to reach k-anon with fewer versions of a reporting script. +* David + * If separating out different scripts for bidding and reporting, could support this. + + +## Follow up on the proposal to support an analytics entity (https://github.com/WICG/turtledove/issues/1115) + + + +* Warren Fernandes + * Was hoping to get some feedback on the analytics entity proposal. + * Got some feedback last time. +* Paul + * Some of the rows in the doc were aggregate statistics + * Events - when we wanted to report them. +* Warren + * If we write to shared storage instead of another reporting output gate, could take advantage of a lot of existing tooling, just reading out of shared storage. + * Followed up on proposal - effectively on the GitHub page +* Paul + * Could take a look at it tomorrow. + * We’ve been thinking more about integrations between Protected Audience and Shared Storage + * Josh filed https://github.com/WICG/turtledove/issues/1190 (Consider adding ability to read Interest Groups in Shared Storage worklets) - more related to cases of shared storage pulling directly from Protected Audience + * Warren - did you want to push stuff from +* Warren + * Want Chrome browser to automatically push a structured JSON object that could be picked up by some entity that could - on behalf of all sellers. +* Paul + * So a push instead of a pull. + * Haven’t had a chance to look further, will very soon. From de3d119aaa4011554922240e6416384a54a8a616 Mon Sep 17 00:00:00 2001 From: Liam Brady Date: Thu, 13 Jun 2024 17:54:35 -0400 Subject: [PATCH 03/13] Spec navigator.canLoadAdAuctionFencedFrame(). (#1205) * spec canLoadAdAuctionFencedFrame() * address comments and fix mandatory unsandboxed flags logic * address comments * Update spec.bs Co-authored-by: qingxinwu <6334674+qingxinwu@users.noreply.github.com> --------- Co-authored-by: qingxinwu <6334674+qingxinwu@users.noreply.github.com> --- spec.bs | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/spec.bs b/spec.bs index a5ba144f5..7f4e68941 100644 --- a/spec.bs +++ b/spec.bs @@ -83,6 +83,13 @@ spec: Shared Storage API; urlPrefix: https://wicg.github.io/shared-storage type: dfn text: shared-storage; url: #permissionspolicy-shared-storage text: shared-storage-select-url; url: #permissionspolicy-shared-storage-select-url +spec: CSP; urlPrefix: https://w3c.github.io/webappsec-csp/ + type: dfn + text: directive name; url: directive-name + text: directive value; url: directive-value +spec: CSPEE; urlPrefix: https://w3c.github.io/webappsec-cspee/ + type: dfn + text: required csp; url: browsing-context-required-csp 
@@ -2615,6 +2622,56 @@ a {{ReportingBrowserSignals}} |browserSignals|, and a [=direct from seller signa
      :: |reportingMacroMap|
 
 
+
canLoadAdAuctionFencedFrame()

+
+*This first introductory paragraph is non-normative.*
+
+The process of running an ad auction through {{Window/navigator}}.{{Navigator/runAdAuction()}} is an
+expensive operation. To prevent wasted cycles if the resulting ad cannot be loaded in the current
+context, {{Window/navigator}}.{{Navigator/canLoadAdAuctionFencedFrame()}} is provided as a method to
+determine, before the ad auction begins, whether an ad auction-created <{fencedframe}> is allowed to
+be loaded in the current context. A <{fencedframe}> has restrictions on where and how it can be
+loaded that do not exist with <{iframe}>s.
+
+
+[SecureContext]
+partial interface Navigator {
+  boolean canLoadAdAuctionFencedFrame();
+};
+
+
+The canLoadAdAuctionFencedFrame() method steps are:
+
+1. Let |global| be [=this=]'s [=relevant global object=].
+
+1. If |global|'s [=Window/browsing context=]'s [=required CSP=] is not null, then return false.
+
+   Note: CSPEE lets arbitrary data flow from an embedder into a <{fencedframe}> via the policies it
+   sets. Since this goes against the privacy guarantees of a Protected Audience-created
+   <{fencedframe}>, this is disallowed.
+
+1. Let |CSPList| be [=this=]'s [=relevant settings object=]'s [=environment settings object/policy
+   container=]'s [=policy container/CSP list=].
+
+1. [=list/For each=] |policy| of |CSPList|:
+
+  1. [=set/For each=] |directive| of |policy|'s [=policy/directive set=]:
+
+    1. If |directive|'s [=directive name|name=] is either "`fenced-frame-src`", "`frame-src`",
+       "`child-src`", or "`default-src`", and if |directive|'s [=directive value|value=] does not
+       [=set/contain=] any of "`https:`", "`https://*:*`", or "`*`", then return false.
+
+1. Let |sandboxFlags| be |global|'s [=associated Document=]'s [=Document/active sandboxing flag
+   set=].
+
+1. If the [=set/intersection=] of |sandboxFlags| and TBD [=set/is not empty=], then return false.
+
+   Issue: TODO: Get the mandatory unsandboxed [=sandboxing flag set=] once it exists in the fenced
+   frame spec. This will then determine the intersection between that and the |sandboxFlags|.
+   (WICG/turtledove#1206)
+
+1. Return true.
+
 # Reporting # {#reporting}
 
 ## {{InterestGroupBiddingAndScoringScriptRunnerGlobalScope/forDebuggingOnly}} ## {#for-debugging-only-header}

From 64d90aa15fa1bcd3415ae63284ae2efe933bae36 Mon Sep 17 00:00:00 2001
From: Michael Kleber 
Date: Tue, 18 Jun 2024 16:41:44 -0400
Subject: [PATCH 04/13] Create 2024-06-12-FLEDGE-call-minutes.md

---
 meetings/2024-06-12-FLEDGE-call-minutes.md | 315 +++++++++++++++++++++
 1 file changed, 315 insertions(+)
 create mode 100644 meetings/2024-06-12-FLEDGE-call-minutes.md

diff --git a/meetings/2024-06-12-FLEDGE-call-minutes.md b/meetings/2024-06-12-FLEDGE-call-minutes.md
new file mode 100644
index 000000000..9462960ce
--- /dev/null
+++ b/meetings/2024-06-12-FLEDGE-call-minutes.md
@@ -0,0 +1,315 @@
+# Protected Audience WICG Calls: Agenda & Notes
+
+Calls take place on most Wednesdays, at 11am US Eastern time; check [#88](https://github.com/WICG/turtledove/issues/88) for exceptions.
+
+That's 8am California = 5pm Paris time = 3pm UTC (during summer)
+
+This notes doc will be editable during the meeting — if you can only comment, hit reload
+
+Notes from past calls are all on GitHub [in this directory](https://github.com/WICG/turtledove/tree/main/meetings).
+
+
+# Next video-call meeting: Wednesday June 12, 2024 
+
+To be added to a Google Calendar invitation for this meeting, join the Google Group https://groups.google.com/a/chromium.org/g/protected-audience-api-meetings/ 
+
+
+## Attendees: please sign yourself in!	 
+
+
+
+1. Michael Kleber (Google Privacy Sandbox)
+2. Luckey Haprley (Remerge)
+3. Roni Gordon (Index Exchange)
+4. David Dabbs (Epsilon)
+5. Matt Menke (Google Chrome)
+6. Orr Bernstein (Google Privacy Sandbox)
+7. Paul Jensen (Google Privacy Sandbox)
+8. Jacob Goldman (Google Ad Manager)
+9. Andrew Pascoe (NextRoll)
+10. Matt Kendall (Index Exchange)
+11. Brian Schmidt (OpenX)
+12. Fabian Höring (Criteo)
+13. Isaac Foster (MSFT Ads)
+14. Konstantin Stepanov (Microsoft Ads)
+15. Victor Pena (Google Chrome)
+16. Jeroune Rhodes (Google Privacy Sandbox) 
+17. Russ Hamilton (Google Privacy Sandbox)
+18. Harshad Mane (PubMatic)
+19. Rickey Davis (Flashtalking)
+20. Paul Spadaccini (Flashtalking)
+21. Becky Hatley (Flashtalking)
+22. Xavier Capaldi (Optable)
+23. Jason Lydon (FT)
+24. Tamara Yaeger (BidSwitch)
+25. Warren Fernandes (Media.net)
+26. Eubert Go (Microsoft Ads)
+27. Maybelline Boon (Google Chrome)
+28. Laura Morinigo (Samsung)
+29. Koji Ota (CyberAgent)
+30. Alexandre Nderagakura (Independant / Consulting)
+31. Matt WIlson (NextRoll)
+32. Jeremy Bao (Google)
+33. Abishai Gray (Google Privacy Sandbox)
+34. Matthew Atkinson (Samsung)
+35. Kenneth Kharma (OpenX)
+36. Arthur Coleman (IDPrivacy)
+37. Kevin Lee (Google)
+38. Denvinn Magsino (Magnite)
+
+
+## Note taker: Tamara Yaeger
+
+
+# Agenda
+
+
+## Process reminder: Join WICG
+
+If you want to participate in the call, please make sure you join the WICG: https://www.w3.org/community/wicg/
+
+Contributions to this work are subject to W3C Community Contributor License Agreement (CLA) which can be found here: https://www.w3.org/community/about/process/cla/ 
+
+
+## Suggest agenda items here:
+
+
+
+*   Isaac Foster:
+    *   Brief revisit the “coarse information sharing” thing, we had talked about setting up time but never did, all got too busy…can even answer here
+    *   Multi Tag Support via “Mixed Ranking”: (really, this + multi tag + bit leak discussion and how we can be creative) https://github.com/WICG/turtledove/issues/846
+    *   Optional decouple bidding/reporting function urls to allow smaller k tuple: https://github.com/WICG/turtledove/issues/679#issuecomment-1703973736
+*   Warren Fernandes:
+    *   Shared storage-based analytics entity proposal: https://github.com/WICG/turtledove/issues/1115 [Shared Storage - PAAPI Analytics Extension Proposal](https://docs.google.com/document/d/1IbHq_XMpK4Q8YqbjSsve1E_Ux_fek_TlpP8vkXMyL38/edit?usp=sharing)https://docs.google.com/document/d/1IbHq_XMpK4Q8YqbjSsve1E_Ux_fek_TlpP8vkXMyL38/edit?usp=sharing 
+
+*   David Dabbs
+    *   API change to trigger a daily update right after a JoinAdInterestGroup event (#1191) 
+https://github.com/WICG/turtledove/issues/1191 
+
+
+# Announcements
+
+The Microsoft Edge folks are holding every-second-Thursday meetings at this same hour to discuss their very similar "Ad Selection API" work.  See https://github.com/WICG/privacy-preserving-ads/issues/50 for logistics.
+
+**Join Privacy Sandbox Developer Webinar: Protected Audience API Reporting**
+
+The Google Privacy Sandbox team will be hosting our next series of webinars on the Protected Audience API. This is the fourth series of webinars covering the Protected Audience API and in this session, we will continue from the previous session and learn more about reporting. The first **Americas friendly session** is happening on** June 25th 3-4 pm ET**. A second **EMEA friendly session** is happening **June 26th 12-1 pm GMT**. 
+
+To join, please register below: 
+
+
+
+*   AMER-friendly: [Register Here](https://rsvp.withgoogle.com/events/protected-audience-webinar-4-reporting2-amer)
+*   EMEA-friendly: [Register Here](https://rsvp.withgoogle.com/events/protected-audience-webinar-4-reporting2-emea)
+
+
+# Notes
+
+Michael (Chrome)
+
+Check the doc for announcements; (1) MSFT Edge folks reg calls about ads select API (like PAAPI); (2) Upcoming webinars on PAAPI reporting - how PAAPI interacts w various reporting mechanisms that exist for learning what happened in auctions, check registration links.
+
+We did PATCHY updates last week. Warren has shared storage analytics proposal, also discussed last week (?) , David has API change to trigger updates, which we haven’t talked about before, let’s start there.
+
+
+## David Dabbs: API change to trigger a daily update right after a JoinAdInterestGroup event (#1191), https://github.com/WICG/turtledove/issues/1191
+
+David (Epsilon)
+
+Google ads is the original poster, Gianni said we should bring it to Wed discussion so I tried to put something on paper. We can have some interesting convos about it. We can open the last comment; basically I tried to put more descript to one of the scenarios that Gianni described, the basic goal is to take expensive IG ‘rendering’ off the main page by joining/planting a minimal set of attributes. Owner update  URL would be required. Means would be a new attribute since Gianni’s proposal to use 2nd parameter doesn’t work because legacy 2nd calling parameter is still supported. The approach would have to be some attribute, regardless of how it’s done.  The ask would be similar to the fetchLater API, which directs event to happen after timeout OR the page is unloaded, whichever happens first, to guarantee that update will be called.
+
+Michael
+
+Looking at the mechanism, it all seems like a good idea. HTTP header-based ways instead of code-on-page or JS API is in line with other parts of PSB. Triggering a daily update earlier than it would otherwise happen as mech for doing quick refreshes plays nicely the way you described it, being able to have minimal amount in HTTP response and defer other work to update that happens shortly thereafter, seems to work well together. 
+
+Obviously fundamentally we can’t add API to say whether user is already in IG or new IG. So using HTTP header to update shortly thereafter has to behave same way as server sending join request, whether user is in the IG already or has just been added. We have to assure desired behavior to avoid unintentionally overwriting stuff. I don’t think it’s a bigger problem in this flow than how it exists today, but people shouldn’t take separation of concerns as if joint action is free; the joint action will have to do over-writing of group that’s already there if it’s in the browser up to this PATCHY thing from last week. 
+
+David
+
+To be clear the initial baseline ask to leave the header activation off the table because base ask is what everybody is already established doing today; access to JS and providing minimal attributes that allows you to use this pattern, and off the main page have the full attribute updates. Once that’s in place the header activation it’s a nice add.  To the comment about overwriting, if someone is coming to the advertiser for the first time or returning, you don’t know whether one is overwriting - that’s how PA is. 
+
+Michael 
+You said something about guarantee to get updated even if user navigates away, we should be able to do something where the user navigating away does not disrupt the queue; but there is no way if user closes browser that we’d still do that update, or do it when they re-open. 
+
+David
+
+If a user goes to a pub site and there are some tabs of auction where you’re eligible, then you get the update, as long as we are guaranteed that the IG was joined back on the advertiser site, we’re good.  
+ 
+Isaac (MSFT Ads)
+
+Minor question, if an update were to be queued and browser closed, Why would the browser not hold onto that for later? 
+ 
+Michael
+
+If you quit the browser it stops doing work. If it re-opens tabs it’s not going to send out network requests that it was thinking about before. 
+
+David
+
+And Fetch Later doesn’t have that?
+
+Isaac
+
+It sounds like there isn’t a mechanism currently to say that the queue comes back after a crash.
+
+Michael
+
+Right, I don’t think it would be desirable for a bunch of reasons.  For one example, if a network request causes a crash and then is called again it could be a cycle, makes user unhappy loop.
+
+David
+
+There is an earlier [issue](https://github.com/WICG/turtledove/issues/82) asking for a header-based API for other IG methods. #1191 only addressed joinAdInterestGroup omitting the others (leaveAdIntertestGroup, clearOriginJoined) because those seem straightforward; they’re basically passing in name + owner.
+
+Michael
+
+Haven’t thought about if it’s important to distinguish those APIs from others.
+
+Warren has the shared storage based analytics entity proposal.
+
+
+## Warren Fernandes: Shared storage-based analytics entity proposal, https://github.com/WICG/turtledove/issues/1115 
+
+Warren (Media.net)
+
+Two important points, buyers don’t get auction ____ so they wouldn’t know, (2) there is not explicit handshake / recognition from the seller that they are acknowledging it exists. Any suggestions on browser signals where this can be indicated or permissioned better?
+
+Paul (Chrome)
+
+If you have an old website, take info, give it to someone else you have to get permission to share that info. Both sides can get the request and approve in response to share information. Don’t have great iea how to do it w analytics, perhaps auction participants can denote who they’re ok sharing their data with (which analytics writers). It seems even harder w buyers than w sellers. We added sellers capability thing where buyers say it’s ok for certain sellers to get info like # of interest groups, etc. In this proposal, what is the idea for getting auction participants to opt into sharing info?
+
+Michael
+
+Is all of the info that we’re talking about all stuff that sellers already get access to? Buyers deliberately when they make bids and pass info, is the info a subset of what they’re already passing to sellers? 
+ 
+Warren
+
+Modeled on that process, info that is already available to sellers. If there is something in there that is not available sellers that would be an oversight. 
+
+Michael
+
+Buyers clearly know they’re passing info to the sellers. If sellers are the only parties we need appropriately empowered to say they are w the analytics entity to pass info that addresses a lot of the concern.
+
+Warren
+
+Like prebid analytics it’s the pub’s choice and if they enable they screen pub pages to some frequency, there is no other direct mechanism for them to be informed. 
+
+Michael
+
+From the precedent POV, I don't think it’s a compelling argument from the browser dev POV. The precedent is that everything that happens in prebid context in shared JS environ in which anybody w code on page can do anything, it’s a cesspool of lack of any control over info sharing that gives browser devs the heebie jeebies. The share of info should be much more explicit than info how it moves around in 1st party webpage that we have today. 
+
+Paul
+
+Thinking about trusted bidding and scoring signals to go to diff origins, we’re talking about opt-in from seller, my idea would be coming from their scoring signals fetch, a header that says analytics provider can get their info. 
+
+Warren
+
+In the case that isn’t permission granted from seller, would you propose that it should be rejected or should the analytics engineer not see them? 
+ 
+Michael
+
+(1) How does seller make clear they’re ok w analytics entity seeing what happened, (2) if pub page says that an analytics entity should see what the auction and seller doesn’t agree, who wins? Pub as owner of page is the one who wins? They can say that component seller can be on their page but disclose the analytics entity. On the other hand it’s plausible that some SSPs don’t want to work w some analytics entities. Whether pubs config of analytics entity overrides and you’re kicked out of the auction seems like a delicate issue where we might need to make it optional or support both ways and let pubs decide whether it’s a precondition, or whether they’re flexible w sellers who don’t report. We’ll have to figure out something that leaves control in hands of owner but that allows for diff possibilities in relation between page owner and various sellers.
+
+Paul
+
+iFrames have security principle that they can’t see what’s happening an in iFrame, so we probably can’t let someone outside an iFrame what’s happening inside. May not be able to differentiate whether seller participated in auction vs participated but didn’t want to share info. 
+
+Michael
+
+Permissions policy model says that iFrame is allowed to load but only if it agrees to certain criteria. 
+
+Paul
+
+We could add very specific permission for certain sellers
+
+Michael
+
+Seems like right semantics; seems like pub should have an option of having that as a way to specify. 
+
+Warren
+
+Same thing, possibly adding indication that pub can send that indicates behavior ; require analytics entity to see bids and any seller who is not ok w that has bids rejected. 
+
+Paul
+
+What do we do when there’s no bids in a particular auction and we don’t ever look at seller’s scoring script. Are we considering always fetching it? 
+
+
+Michael
+
+But if it comes from response header, the usual would be request header from script; this would be set of entities that pub is asking about. 
+
+Paul
+
+Tricky is if we wanted add anything we’d all have to update the version
+
+Michael
+
+We’ll think about details on how to enable it, but we’re all aligned. I think it’s good we don’t need to figure out a separate mechanism for buyer opt-in as well. We’ll continue in github issue.
+
+Ok we’ve done the Warren issue and the David issue and Isaac had to drop, which means we have no more agenda items?
+
+
+## Blink Launch Process
+
+David
+
+Question – I noticed over past week a number of intent to ships that got their LGTM x3, the render size, reporting timeouts and multiple bids, curious if those are things that are already there and will be ramped up? Is there was to find out if it’s only on the feature card? Which milestone will render them fully available? 
+
+Paul
+
+Our general way of launching has been to start w Chrome Canary channel, we enable 50% testing on Canary. Within week dev follows that. After we’ve done that a couple weeks and make sure we don’t cause crashes, we move onto Beta. 50% same thing, check metrics for a few weeks, then move to stable 1%. After 2 weeks on stable 1%, we get more data on each stage of rollout, if it looks good at 1% stable we go to 100% stable. We do that by landing a CO that turns it on by default, tip of tree, whatever branch that is. beyond that point it will have specific point of data how it lands, and it will be on forever unless we emergency turn it off. 
+
+Through all these diff channels we try to have feat detect mechanisms available so you can tell what’s on and available. There’s also the Chrome status entries, we should probably update those more. The feature card - chromestatus.com (?) We should update that to say when something shipped but not sure we do. 
+
+David
+
+It sounded like one of them was being ramped to some % stable, but it may not be the case. It already has to go then you ramp it 100%.
+
+Paul
+
+If we do 50% canary, 50% dev, 1% stable, 100% stable, we have to have it approved by 3 of the Blink API owners. We can never get to 100% stable until we have the intent to ship approved by 3 people.  For more details see https://www.chromium.org/blink/launching-features/ 
+
+David  
+
+Also the trusted bidding signals, the cross origin had updates to fix the spec. It won’t affect it’s progress, just tweaks?
+
+Paul
+
+We ship change, sometimes we’ll forget something, the explainer….. (?)
+
+Roni (Index)
+
+How do we know it’s hit 100% stable?
+
+Paul
+
+Before we ramp it up to 100% stable, we’ll turn it on tip of tree, if you look at that CO you can copy paste the commit hash to the Chrome dashboard and it will tell you what release that particular CO went out to, we release a canary every day. Generally we will enable it by default on – imagine we put something today; the code would be there but it wouldn’t be on. Then let’s say intent to ship approved, + 6-8 weeks from now we would turn it on at tip of tree; 8 weeks is 2 milestones later, so that milestone would be on by default for everyone. Shortly after we enable by default by tip of tree, we’ll enable using controls for all branches. It’s on by default but we can really turn it on for all stable users when code is written. 
+
+On the github issue, we try and say when it’s going to canary and then beta and then stable, that’s a specific place for each specific feature.
+
+Roni
+
+I keep track of every github issue, but for other that don’t it would be very helpful to see it somewhere together.
+
+Michael
+
+The webby answer here is that feature detection is better than on-by-default starting at milestone-whatever. Even if we say we’re turning something on by default in M-whatever, it’s not that you can just check something is sufficiently high milestone for it to be on because there are not the browsers that make separate decisions about thinks. If Edge turns out API selection and has some feature diffs, and you think it’s a high enough milestone, you might get it wrong. Feature detection is preferable because it’ll get the answer right every time as opposed to having edge cases.
+
+Roni
+
+Last week we were trying to figure out where the main plus delta is; I would love to know everything about everything, but if every auction includes 200 items out of which 197 have been stable we’re losing our signal to ratio.
+
+Paul
+
+Last week decided to prevent this sort of accumulation of long-term features, don’t know if we’ve done that yet. Thinking about how to ensure that list is not huge also, I think Pat’s concern was about sending it to servers. You could send a hash but you need a decoder ring. Otherwise the not-on-default version is what we’re talking about.
+
+Michael
+
+Sensible things that go well together
+
+Paul
+
+May be hard to implement, but… we can try to think about that. 
+
+Michael
+
+**NOTE: No call next week, Wed June 19 = Juneteenth US Federal Holiday.  See you June 26.**

From d9983cf9eb6b02049eadad873241323abb69b78d Mon Sep 17 00:00:00 2001
From: Omri Ariav 
Date: Thu, 20 Jun 2024 19:45:00 +0300
Subject: [PATCH 05/13] Add Taboola to fledge-tester-list.md (#1208)

---
 fledge-tester-list.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fledge-tester-list.md b/fledge-tester-list.md
index 48a297eb8..8ffad7853 100644
--- a/fledge-tester-list.md
+++ b/fledge-tester-list.md
@@ -87,6 +87,7 @@ The usefulness of this page depends on testers sharing information and updates.
 | Kargo | SSP | H2 2024 | | privacysandbox@kargo.com |
 | Lucead | DSP & SSP | Testing in progress | | privacysandbox@lucead.com |
 | Optable | DSP & SSP | Testing in progress | | privacysandbox@optable.co |
+| Taboola | DSP & SSP | Testing in progress | | privacy-sandbox@taboola.com |
 
 ## Table - Publishers and Advertisers Interested in Testing or Early Adoption
 Companies who may be interested in participating in tests and early adoption opportunities provided by ad tech companies.

From 3779f0fcbd5da37a20cf96befb1b0ecaee987874 Mon Sep 17 00:00:00 2001
From: Isaac Foster 
Date: Fri, 21 Jun 2024 15:08:47 -0400
Subject: [PATCH 06/13] Add Clarifying Note About Cross Origin Retrieval Header
 for Delegation File (#1029)

Ran into this while testing, probably should be assumed but wanted to save someone else the trouble.
---
 FLEDGE.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/FLEDGE.md b/FLEDGE.md
index fea63b471..1125b6c42 100644
--- a/FLEDGE.md
+++ b/FLEDGE.md
@@ -292,7 +292,7 @@ If any of these per-owner limits are exceeded, the interest group(s) that would
 
 #### 1.3 Permission Delegation
 
-When a frame navigated to one domain calls joinAdInterestGroup(), leaveAdInterestGroup(), or clearOriginJoinedAdInterestGroups() for an interest group with a different owner, the browser will fetch the URL https://owner.domain/.well-known/interest-group/permissions/?origin=frame.origin, where `owner.domain` is domain that owns the interest group and `frame.origin` is the origin of the frame. The fetch uses the `omit` [credentials mode](https://fetch.spec.whatwg.org/#concept-request-credentials-mode), using the [Network Partition Key](https://fetch.spec.whatwg.org/#network-partition-keys) of the frame that invoked the method. To avoid leaking cross-origin data through the returned Promise unexpectedly, the fetch uses the `cors` [mode](https://fetch.spec.whatwg.org/#concept-request-mode). The fetched response should have a JSON MIME type and be of the format:
+When a frame navigated to one domain calls joinAdInterestGroup(), leaveAdInterestGroup(), or clearOriginJoinedAdInterestGroups() for an interest group with a different owner, the browser will fetch the URL https://owner.domain/.well-known/interest-group/permissions/?origin=frame.origin, where `owner.domain` is domain that owns the interest group and `frame.origin` is the origin of the frame. The fetch uses the `omit` [credentials mode](https://fetch.spec.whatwg.org/#concept-request-credentials-mode), using the [Network Partition Key](https://fetch.spec.whatwg.org/#network-partition-keys) of the frame that invoked the method. To avoid leaking cross-origin data through the returned Promise unexpectedly, the fetch uses the `cors` [mode](https://fetch.spec.whatwg.org/#concept-request-mode). The fetched response should have a JSON MIME type, have a `Access-Control-Allow-Origin` that allows it to load from the calling origin, and be of the format:
 
 ```
 { "joinAdInterestGroup": true/false,

From a2185f67c1ff1186c78f399b97d2e98aedd7cb60 Mon Sep 17 00:00:00 2001
From: Michael Kleber 
Date: Tue, 2 Jul 2024 15:17:04 -0400
Subject: [PATCH 07/13] Create 2024-06-26-FLEDGE-call-minutes.md

---
 meetings/2024-06-26-FLEDGE-call-minutes.md | 260 +++++++++++++++++++++
 1 file changed, 260 insertions(+)
 create mode 100644 meetings/2024-06-26-FLEDGE-call-minutes.md

diff --git a/meetings/2024-06-26-FLEDGE-call-minutes.md b/meetings/2024-06-26-FLEDGE-call-minutes.md
new file mode 100644
index 000000000..f06582857
--- /dev/null
+++ b/meetings/2024-06-26-FLEDGE-call-minutes.md
@@ -0,0 +1,260 @@
+
+# Protected Audience WICG Calls: Agenda & Notes
+
+Calls take place on most Wednesdays, at 11am US Eastern time; check [#88](https://github.com/WICG/turtledove/issues/88) for exceptions.
+
+That's 8am California = 5pm Paris time = 3pm UTC (during summer)
+
+This notes doc will be editable during the meeting — if you can only comment, hit reload
+
+Notes from past calls are all on GitHub [in this directory](https://github.com/WICG/turtledove/tree/main/meetings).
+
+
+# Next video-call meeting: Wednesday June 26, 2024 
+
+To be added to a Google Calendar invitation for this meeting, join the Google Group https://groups.google.com/a/chromium.org/g/protected-audience-api-meetings/ 
+
+
+## Attendees: please sign yourself in!	 
+
+
+
+1. Paul Jensen (Google Privacy Sandbox)
+2. Sven May (Google Privacy Sandbox)
+3. Brian May (Dstillery)
+4. David Dabbs (Epsilon)
+5. Ricardo Bentin (Media.net)
+6. Matt Davies (Bidswitch | Criteo)
+7. Roni Gordon (Index Exchange)
+8. Youssef Bourouphael (Google Privacy Sandbox)
+9. Garrett McGrath (Magnite)
+10. Jacob Goldman (Google Ad Manager)
+11. Matt Kendall (Index Exchange)
+12. Aymeric Le Corre (Lucead)
+13. Matt Menke (Google Chrome)
+14. Alonso Velasquez (Google Privacy Sandbox)
+15. Sathish Manickam (Google Privacy Sandbox)
+16. Orr Bernstein (Google Privacy Sandbox)
+17. David Tam (Relay42)
+18. Yanay Zimran (Start.io)
+19. Denvinn Magsino (Magnite)
+20. Gianni Campion (Google ads)
+21. Arthur Coleman (IDPrivacy)
+22. Laurentiu Badea (OpenX)
+23. Abishai Gray (Google Privacy Sandbox)
+24. Lydon, Jason (FT)
+25. Becky Hatley (Flashtalking)
+26. Anthony Yam (Flashtalking)
+27. Owen Ridolfi (Flashtalking)
+28. Rickey Davis (Flashtalking)
+29. Itay Sharfi (Google)
+30. Manny Isu (Google Privacy Sandbox)
+31. Tamara Yaeger (BidSwitch)
+32. Warren Fernandes (Media.net)
+33. Koji Ota(CyberAgent)
+34. Maybelline Boon (Google Privacy Sandbox)
+35. Matthew Atkinson (Samsung)
+36. Andrew Pascoe (NextRoll)
+37. Alex Peckham (Flashtalking)
+38. Tal Bar Zvi (Taboola)
+39. Luckey Harpley (Remerge)
+
+
+## Note taker: Orr Bernstein	
+
+
+# Agenda
+
+
+## Process reminder: Join WICG
+
+If you want to participate in the call, please make sure you join the WICG: https://www.w3.org/community/wicg/
+
+Contributions to this work are subject to W3C Community Contributor License Agreement (CLA) which can be found here: https://www.w3.org/community/about/process/cla/ 
+
+
+## Suggest agenda items here:
+
+
+
+*   Isaac Foster:
+    *   Trusted Scoring Signals for Financials: Via [Comment](https://github.com/WICG/turtledove/issues/824#issuecomment-2198376904) on [Roni Original](https://github.com/WICG/turtledove/issues/824) 
+    *   Brief revisit the “coarse information sharing” thing, we had talked about setting up time but never did, all got too busy…can even answer here
+    *   Multi Tag Support via “Mixed Ranking”: (really, this + multi tag + bit leak discussion and how we can be creative) https://github.com/WICG/turtledove/issues/846
+    *   Optional decouple bidding/reporting function urls to allow smaller k tuple: https://github.com/WICG/turtledove/issues/679#issuecomment-1703973736 \
+
+*   Alexander Tretyakov (Google Privacy Sandbox)
+    *   Hybrid protocol – modify v2 protocol so that a single request can go to both BYOS and TKV servers. This is meant to be a temporary measure, and when the enforcement starts only TKV mode will be supported. The benefits of the hybrid protocol are:
+        *   enables piecemeal migration. AdTechs can migrate pieces of their logic and asses the cost/latency and other parameters before fully committing
+        *   allows keeping parts of the logic that are not currently supported by TKV in BYOS, while moving the rest to TKV.
+*   Roni Gordon
+    *   We’re observing **biddingDurationMsec** values in production well above the default 50ms timeout (i.e. with the default auctionConfig values) – some as high as 322ms – can you think of any explanation for this behaviour?
+        *   Haven’t yet logged an GH issue since we haven’t been able to reproduce in controlled tests, where the time spent in generateBid() seems to match the fDO QSP
+    *   Can we discuss the implications of the tweaks to the deals proposal?
+        *   https://github.com/WICG/turtledove/issues/873
+*   Warren Fernandes
+    *   Continued discussion on the addition of analytics entities to PA auctions: https://github.com/WICG/turtledove/issues/1115
+    *   New mechanism for seller opt-in proposed.
+*   David Tam
+    *   There are 3 parties that can create IGs, the buyer (advertiser), the buyer’s delegated tech partner and the publisher.  I would like to understand how a buyer would be able to bid for publisher curated IGs - https://github.com/WICG/turtledove/issues/1196 
+*   Gianni Campion (briefly discuss 0 ads API for joinIG
+    *   https://github.com/WICG/turtledove/issues/1191)
+*   Yao Xiao
+    *    discuss header api for joinIG https://github.com/WICG/turtledove/issues/82
+
+
+# Announcements
+
+The Microsoft Edge folks are holding every-second-Thursday meetings at this same hour to discuss their very similar "Ad Selection API" work.  See https://github.com/WICG/privacy-preserving-ads/issues/50 for logistics.
+
+**Join Privacy Sandbox Developer Webinar: Protected Audience API Reporting**
+
+The Google Privacy Sandbox team will be hosting our next series of webinars on the Protected Audience API. This is the fourth series of webinars covering the Protected Audience API and in this session, we will continue from the previous session and learn more about reporting. The first **Americas friendly session** is happening on** June 25th 3-4 pm ET**. A second **EMEA friendly session** is happening **June 26th 12-1 pm GMT**. 
+
+To join, please register below: 
+
+
+
+*   AMER-friendly: [Register Here](https://rsvp.withgoogle.com/events/protected-audience-webinar-4-reporting2-amer)
+*   EMEA-friendly: [Register Here](https://rsvp.withgoogle.com/events/protected-audience-webinar-4-reporting2-emea)
+
+
+# Notes
+
+
+## Roni Gordon: We’re observing biddingDurationMsec values in production well above the default 50ms timeout (i.e. with the default auctionConfig values) – some as high as 322ms – can you think of any explanation for this behaviour?
+
+
+
+*   Roni Gordon
+    *   Have observed. Bidding_duration_msec is the time that generateBid spends? Having trouble reconciling how this can be significantly higher than what we would see based on the timeout.
+*   Paul Jensen
+    *   Asked the PA team how the bidding_duration_msec could be higher than the timeout. Largely historical reasons. The way it works is the perBuyerTimeout - which defaults to 50 ms - added way back in the beginning. In the implementation/spec, you can see that that one is tied to how much time it takes that one to execute the generateBid JavaScript, does not include the time for setup - create a JS execution context, initialize 7000 built-ins in JavaScript, then move those into the JS context. Can add a lot more time; these are all part of bidding_duration_msec because it’s all “the cost of generating the bid”, but for the timeout, we only enforce that on the generateBid call in JS. All measured using different timers, browser is running in a very multi-threaded environment, some of these threads are getting preempted at random points. This is the reason why there’s a bid difference between bidding_duration_msec, which includes the setup, and the timeout, which doesn’t.
+*   Brian May
+    *   Timeout is the max amount of time that the code can run for, but the bidding duration is how long it took including a bunch of setup. Not based on the same thing.
+*   Paul
+    *   If you use a debugger - attach via Chrome Developer Tools - the timeout would pause, because otherwise the timeout would always be exceeded because of a breakpoint; but the bidding duration msec is just a timer, so it would report the time even when it was paused at that breakpoint.
+    *   While on the subject of per-buyer-timeouts, it was one of the first things we added to PA. We’ve sort of moved away from that to some degree. It made the browser opinionated on how many IGs you should have and how fast each of them should be. Wanted to make the browser less opinionated - maybe you have one IG that’s particularly important and you want to spend more time calculating the bid there because maybe it’s a bigger bid. So moving away from per-buyer timeout, and towards cumulative IG - controls the whole of all the interest groups, how long they can spend in aggregate. There’s a devrel website that describes the differences between these, and how the cumulative timeout gives people a bit more freedom.
+*   Brian (by chat)
+    *   https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/latency
+*   Roni
+    *   I thought this was a measure of the time spent on device in the generate bid function alone – seems like it also includes all the initialization pre-work required to get to execution of generateBid. It would be great to elaborate on this in the spec on what’s it’s measuring.
+*   David Dabbs
+    *   In the spec, it says the reporting timeout is clamped to 5 seconds. Is there something similar for the per-buyer cumulative timeout? Seems like it should be mentioned in the explainer.
+*   Matt Menke (by chat)
+    *   There's no max for cumulative timeout
+    *   By default there is no timeout
+*   Paul
+    *   The difference in incentivization is perhaps the reason why one is capped and one is not capped.
+*   Matt
+    *   For reporting, it’s a background thing. You will typically navigate to a different page, maybe by clicking on an ad. Don’t want the reporting to keep on going for an excessively long time.
+
+
+## https://github.com/WICG/turtledove/issues/873
+
+
+
+*   Roni Gordon
+    *   Trying to ascertain whether or not its possible to have a dealID visible in the reporting.  In other words, can you have a ‘split-brain’ situation where scoreAd seems dealID bids but reportResult doesn’t?
+*   Paul Jensen
+    *   To refresh folks, the proposal that Roni put up on March 13 - issue 873 - taking an existing field that’s part of the ad part of the interest group - existing field is called buyerAndSellerReportingID - a string - and making it into an array of strings, and allowing the buyer to pick one of them and to have that chosen deal passed along to scoreAd and reportResult. So, as Roni noted, the same thing is available at scoreAd time - to assess the score if there’s some discount - and at reportingTime - so that we can account for how the desirability score was arrived at, and to keep track of who’s buying with a particular deal, keep track of that. Like buyerAndSellerReportID, it will have a k-anonymity reqiuirement on it. Could appear in scoreAd, but would only be visible for reporting functions if it’s k-anonymous with the URL and interest group owner. Part of Leeron’s proposal was to give buyers a way to say that the buyerAndSellerReportingID being passed through to reporting is required. You an imagine, if it’s not k-anonymous, without the deal ID, the bid might not make sense at a later time when the reports are benign processed, so we expose this boolean to the buyer to only report to scoring if it’s k-anonymous.
+*   Roni Gordon
+    *   The way k-anon works for everything else - you have to end up with the seller choosing to select the ad in order for the k-anon to be ticked; otherwise, it never starts. What I wanted to confirm is that the same thing is happening here; you can score a deal bid with all the required parameters.
+*   Paul
+    *   We give the buyer the ability to throw away a bid if the deal ID is not k-anon, you want to give the seller the same. We could expose a boolean, and seller can require that boolean to always to be true, that the deal id has to be k-anon to be used.
+*   Roni
+    *   Yes, but also, if a seller rejects deal bids that are k-anon, it will never be k-anon – how so would that dealID ever reach the threshold?
+*   Brian
+    *   Can we do this retroactively, at the point at which k-anon is reached, that we can report a deal ID that was not previously reported because it wasn’t yet k-anon.
+*   Matt
+    *   Can’t convey whether it’s k-anon, or you could game k-anon. Need some way to say, if it’s not k-anon, don’t let it win. Specifically if it’s not k-anon because of the deal ID, but would be k-anon.
+*   Paul
+    *   What if we allow everything to be scored, even if it’s not k-anonymous. Two winners - the k-anonymous winner and the non-k-anonymous winner. Sometimes you only have one or the other. For the non-k-anonymous winner, we could increment the k-anonymity count, and we’ll do it for the k-anonymous winner as well. This is what Leeron had planned for deal support, was at the bottom of his proposal. What I had suggested earlier of exposing that boolean to scoreAd, could still increment their k-count.
+*   Roni
+    *   If it doesn’t meet the threshold, it’s discarded from the auction. Optional is whether or not it gets to the seller or not, if it gets to the seller, score it as normal. Just wanted to make sure that this is the behavior we’re getting, and not that reportResult is getting the winner without deal ID.
+*   Paul
+    *   Yes, we could always expose the boolean. We don’t want to expose whether it’s k-anon early to avoid gaming. Want to know the highest non-k-anonymous winner so that we can increment its k-anonymity count. So I think we can expose that boolean to sellers to ensure that they can choose to only allow winners that would be reported correctly.
+*   Roni
+    *   Seems like something we’d always want, but I’ll take the boolean in scoreAd, because for forDebugOnly, it’ll help make it obvious what’s happening. Absent k-anon enforcement, as many scoring bids I score is how many bids I submit to the upstream seller. As soon as we include k-anon, that number could be anything. The scoring counts are way off. It would be nice to see that if I submit a non-desirability score of non-zero.
+*   Paul
+    *   I think we have a private aggregation on whether a bid is not used because of k-anon.
+*   Roni
+    *   The current proposal with tweaks?
+*   Paul
+    *   We already have the boolean for buyers, so what we’d change is to expose that boolean to the seller so that the seller could reject any bid from an IG that doesn’t have that boolean set, since it can’t guarantee that this bid would be correctly reported. 
+*   Brian May
+    *   What does the boolean say?
+*   Paul
+    *   The boolean is provided by buyer and says that they want their bid to be thrown away if their bid - with the buyerAndSellerReportingID - is not k-anonymous. If it’s false, it can continue onwards.
+*   Brian
+    *   Can we simplify that it’s reportable to all parties? Boolean that says that this thing is going to be reportable to everybody.
+*   Paul
+    *   I think this is for everybody.
+*   Brian
+    *   Language there that this is about deals.
+*   Paul
+    *   Not sure I totally understand, but I think we’re aligned. Maybe if you could put it on the issue, I could better understand. And I’ll try to add more detail on the issue.
+*   Giani Campion
+    *   Where is the boolean available? Does it cover buyerReportingID as well?
+*   Paul
+    *   Indicates that the bid should be thrown away if the reporting ID is not k-anonymous. It covers both buyerReportingID and buyerAndSellerReportingID.
+
+
+## Continued discussion on the addition of analytics entities to PA auctions: https://github.com/WICG/turtledove/issues/1115 
+
+New mechanism for seller opt-in proposed
+
+
+
+*   Warren Fernandes
+    *   Following up on the conversation from last time; request for some sort of mechanism for both the seller to be aware that they had analytics available. Proposed header that could be set on the call to the seller decision logic file that included a list of analytics entities that were present and another head they could respond with. Additional flag that the sellers could host on the well-known URL to indicate whether they had opted out of being observed by the analytics entity.
+*   Paul
+    *   Sounds like you made the updates we’d talked about before. Did you want to discuss a part of that, or is this a request to take another look?
+*   Warren
+    *   The latter. Is this good to go, want some feedback. Not really sure how to proceed at this point, so any feedback on that would be great.
+*   Paul
+    *   I can take another look at that. May be less available in the next couple of weeks, but will try to take a look at it in the coming month, or to find someone else who can take a look sooner.
+
+
+## There are 3 parties that can create IGs, the buyer (advertiser), the buyer’s delegated tech partner and the publisher.  I would like to understand how a buyer would be able to bid for publisher curated IGs - https://github.com/WICG/turtledove/issues/1196
+
+
+
+*   David Tam
+    *   As I understand it, there are three parties that can create an IG - buyer, delegated buyer, or publisher. For publisher, I assume that the publisher wants to monetize an IG and sell it to interested buyers. How would a buyer actually buy an IG?
+*   Alonso
+    *   We don’t have my product peers on the call who have been thinking about this from the publisher side of things, but it’s a known request. I do see issue 1196, we’ll tag it for follow-up here. We’ll follow up.
+*    David
+    *   Is it right that a publisher might want to sell an IG to a DSP?
+*   Alonso
+    *   You’re showing a new use case. If you have any hypotheses, please feel free to post them to 1196. 
+    *   In this use case, an audience, by the publisher - what’s the scope of that audience? A little more clarify on the use case helps us. A lot of what we do is to ensure that we’re not creating  cross-site profiles. If you have those ideas, please add them to 1196.
+*   Matt Davies (by chat)
+    *   what about other 3rd party entities?
+    *   Data providers, Pubs, other entities
+*   Brian May
+    *   Original FLEDGE proposal was that someone else could create an IG and cede ownership. This sounds like a different use case.
+*   Alonso
+    *   Would like to better understand the delta in these use cases.
+*   Paul
+    *   The other thing that would help us understand the use case better is understanding how the seller or delegation of the IG would work. Today, it’s possible for whoever creates the IG to maintain control, still do things on another party’s behalf, could still grow/shrink/control the bidding directly. Sounds like something less tightly coupled; many of the behaviors are controlled by the new owner.
+*   David
+    *   Yes, if you’ve got multiple publishers, want to basically create a single IG and monetize that. Another use case is to funnel activity through a PA audience.
+*   Paul
+    *   PA doesn’t limit the sites that you’re joining from. Could have a third party iframe that joins from all different sites. The publishers could kind of pick that, join IGs from different sites.
+*   Brian
+    *   Is this about giving publishers a mean of getting credit when an iG they created is monetized by somebody?
+*   David
+    *   Essentially, yes. It’s an interesting use case where we can buy publisher-created interest groups. Some way of informing the buyer that this is the IG, would you like to buy it?
+*   Brian
+    *   Maybe a different direction - could inform  the creator of the IG that somebody has bought against it.
+*   David
+    *   Because the seller initiated the auction, from my view, it just needs to be added into the auction confirm.
+*   Matt Davies
+    *   It could be useful for publishers, but what about other types of ad techs? The second you start adding in third parties to the mix, e.g. BidSwitch, they’re an interested party in the mix.
+*   Brian
+    *   It’s not about the creation; it’s about ownership once created.
+*   Brian
+    *   Bidding logic, reporting API callouts - all of that, who’s getting those calls.
+*   Alonso
+    *   Issue [1196](https://github.com/WICG/turtledove/issues/1196) is timely to galvanize the sell-side, looking into buy-side as well which is[ issue 1028](https://github.com/WICG/turtledove/issues/1028)  If you have thoughts about that, I’d love to hear your thoughts in a future WICG.

From 47dd4409bde9b68dca43cfe797f239bd9abaf68f Mon Sep 17 00:00:00 2001
From: Maks Orlovich 
Date: Wed, 3 Jul 2024 13:12:04 -0400
Subject: [PATCH 08/13] Some first steps towards expression some fetch
 parallelism.

---
 spec.bs | 224 ++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 136 insertions(+), 88 deletions(-)

diff --git a/spec.bs b/spec.bs
index 9e146b0c9..4cac4574e 100644
--- a/spec.bs
+++ b/spec.bs
@@ -1486,8 +1486,10 @@ a {{DirectFromSellerSignalsForBuyer}} |directFromSellerSignalsForBuyer|, a [=dur
     1. [=map/Set=] |prevWinIDL|["{{PreviousWin/adJSON}}"] to |prevWin|'s [=previous win/ad json=].
     1. [=list/Append=] |prevWinIDL| to |prevWins|.
   1. [=map/Set=] |browserSignals|["{{BiddingBrowserSignals/prevWinsMs}}"] to |prevWins|.
-  1. Let « |biddingScript|, ignored » be the result of [=fetching script=] with
+  1. Let |biddingScriptFetcher| be the result of [=creating a new script fetcher=] with
     |ig|'s [=interest group/bidding url=].
+  1. Let |biddingScript| be the result of [=waiting for script body from a fetcher=] given
+     |biddingScriptFetcher|.
   1. If |biddingScript| is failure, return failure.
   1. If |ig|'s [=interest group/bidding wasm helper url=] is not null:
     1. Let |wasmModuleObject| be the result of [=fetching WebAssembly=] with |ig|'s
@@ -1527,9 +1529,8 @@ To generate and score bids given an [=auction config=] |auctionConfig
 |bidDebugReportInfoList|:
 1. [=Assert=] that these steps are running [=in parallel=].
 1. Let |auctionStartTime| be the [=current wall time=].
-1. Let « |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom| » be the result of
-  [=fetching script=] with |auctionConfig|'s [=auction config/decision logic url=].
-1. If |decisionLogicScript| is failure, return null.
+1. Let |decisionLogicFetcher| be the result of [=creating a new script fetcher=] with
+  |auctionConfig|'s [=auction config/decision logic url=].
 1. Let |seller| be |auctionConfig|'s [=auction config/seller=].
 1. Let « |bidGenerators|, |negativeTargetInfo| » be the result of running
   [=build bid generators map=] with |auctionConfig|.
@@ -1559,12 +1560,12 @@ To generate and score bids given an [=auction config=] |auctionConfig
       1. Set |topLevelDirectFromSellerSignalsRetrieved| to true.
     1. If |compWinnerInfo|'s [=leading bid info/leading bid=] is not null, then run
       [=score and rank a bid=] with |auctionConfig|, |compWinnerInfo|'s
-      [=leading bid info/leading bid=], |leadingBidInfo|, |decisionLogicScript|,
-      |allowCrossOriginTrustedScoringSignalsFrom|, null, "top-level-auction", null, and |topLevelOrigin|.
+      [=leading bid info/leading bid=], |leadingBidInfo|, |decisionLogicFetcher|,
+      null, "top-level-auction", null, and |topLevelOrigin|.
     1. If |compWinnerInfo|'s [=leading bid info/leading non-k-anon-enforced bid=]
       is not null, then run [=score and rank a bid=] with |auctionConfig|,
       |compWinnerInfo|'s [=leading bid info/leading non-k-anon-enforced bid=],
-      |leadingBidInfo|, |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom|, null,
+      |leadingBidInfo|, |decisionLogicFetcher|, null,
       "top-level-auction", null, and |topLevelOrigin|.
     1. Decrement |pendingComponentAuctions| by 1.
   1. Wait until |pendingComponentAuctions| is 0.
@@ -1631,7 +1632,7 @@ To generate and score bids given an [=auction config=] |auctionConfig
 1. Let |pendingAdditionalBids| be the [=list/size=] of |additionalBids|.
 1. [=list/For each=] |additionalBid| of |additionalBids|, run the following steps [=in parallel=]:
   1. [=Score and rank a bid=] with |auctionConfig|, |additionalBid|, |leadingBidInfo|,
-    |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom|, null, |auctionLevel|,
+    |decisionLogicFetcher|, null, |auctionLevel|,
     |componentAuctionExpectedCurrency|, and |topLevelOrigin|.
   1. Decrement |pendingAdditionalBids| by 1.
 1. Let |settings| be |global|'s [=relevant settings object=].
@@ -1789,9 +1790,8 @@ To generate and score bids given an [=auction config=] |auctionConfig
             1. If |bidToScore|'s [=generated bid/for k-anon auction=] is true,
                 [=list/append=] |bidToScore|'s [=generated bid/interest group=] to |bidIgs|.
             1. [=Score and rank a bid=] with |auctionConfig|, |bidToScore|, |leadingBidInfo|,
-              |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom|,
-              |directFromSellerSignalsForSeller|, |dataVersion|, |auctionLevel|,
-              |componentAuctionExpectedCurrency|, and |topLevelOrigin|.
+              |decisionLogicFetcher|, |directFromSellerSignalsForSeller|, |dataVersion|,
+              |auctionLevel|, |componentAuctionExpectedCurrency|, and |topLevelOrigin|.
   1. Decrement |pendingBuyers| by 1.
 1. Wait until both |pendingBuyers| and |pendingAdditionalBids| are 0.
 1. If |leadingBidInfo|'s [=leading bid info/leading bid=] is null, return null.
@@ -1876,8 +1876,8 @@ To convert to an AuctionAd sequence given a [=list=]-or-null |ads|:
 
 

 To fetch and decode trusted scoring signals given an [=auction config=] |auctionConfig|,
-a [=generated bid=] |generatedBid|, a [=list=] of [=origins=]
-|allowCrossOriginTrustedScoringSignalsFrom|, and an [=origin=] |topLevelOrigin|:
+a [=generated bid=] |generatedBid|, a [=script fetcher=] |decisionLogicFetcher|, and an [=origin=]
+|topLevelOrigin|:
 
 1. Let |crossOriginTrustedScoringSignalsOrigin| be null.
 1. Let |sameOriginTrustedScoringSignals| be null.
@@ -1916,6 +1916,8 @@ a [=generated bid=] |generatedBid|, a [=list=] of [=origins=]
   1. If |fullSignalsUrl|'s [=url/origin=] is not [=same origin=] with |auctionConfig|'s
      [=auction config/seller=], then:
       1. Set |crossOriginTrustedScoringSignalsOrigin| to |fullSignalsUrl|'s [=url/origin=].
+      1. Let |allowCrossOriginTrustedScoringSignalsFrom| be the result of [=wait for cross origin
+        trusted scoring signals authorization from a fetcher=] given |decisionLogicFetcher|.
       1. If |allowCrossOriginTrustedScoringSignalsFrom| does not [=list/contain=]
         |crossOriginTrustedScoringSignalsOrigin|:
         1. Set |crossOriginTrustedScoringSignalsOrigin| to null.
@@ -1955,7 +1957,7 @@ a [=generated bid=] |generatedBid|, a [=list=] of [=origins=]
 

 To score and rank a bid given an [=auction config=] |auctionConfig|, a [=generated bid=]
 |generatedBid|, a [=bid debug reporting info=] |bidDebugReportInfo|, a [=leading bid info=] |leadingBidInfo|,
-a [=string=] |decisionLogicScript|, a [=list=] or [=origins=] |allowCrossOriginTrustedScoringSignalsFrom|,
+a [=script fetcher=] |decisionLogicFetcher|,
 a {{DirectFromSellerSignalsForSeller}} |directFromSellerSignalsForSeller|, an {{unsigned long}}-or-null
 |biddingDataVersion|, an enum |auctionLevel|, which is "single-level-auction", "top-level-auction",
 or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, and an [=origin=]
@@ -1963,8 +1965,8 @@ or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, a
 
 1. Let «|crossOriginTrustedScoringSignalsOrigin|, |sameOriginTrustedScoringSignals|,
   |crossOriginTrustedScoringSignals|, |scoringDataVersion|» be the result of [=fetch and
-  decode trusted scoring signals=] given |auctionConfig|, |generatedBid|,
-  |allowCrossOriginTrustedScoringSignalsFrom|, |topLevelOrigin|.
+  decode trusted scoring signals=] given |auctionConfig|, |generatedBid|, |decisionLogicFetcher|,
+  |topLevelOrigin|.
 1. Let |adMetadata| be |generatedBid|'s [=generated bid/ad=].
 1. Let |bidValue| be |generatedBid|'s [=generated bid/bid=].
 1. If |generatedBid|'s [=generated bid/modified bid=] is not null, then set |bidValue| to
@@ -2000,6 +2002,9 @@ or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, a
     
The result of running [=is debugging only in cooldown or lockout=] with |seller|
   
 
+1. Let |decisionLogicScript| be the result of [=wait for script body from a fetcher=] given
+  |decisionLogicFetcher|.
+1. If |decisionLogicScript| is falure, return.
 1. Let « |scoreAdResult|, |debugWinReportUrl|, |debugLossReportUrl| » be the result of
   [=evaluating a scoring script=] with |decisionLogicScript|, |adMetadata|,
   |bidValue|'s [=bid with currency/value=], |auctionConfig|'s [=auction config/config idl=],
@@ -2180,74 +2185,6 @@ To validate fetching response given a [=response=] |response|, null,
   1. Return true.
 

 
-The Ad-Auction-Allow-Trusted-Scoring-Signals-From HTTP response header is a
-[=structured header=] whose value must be a [=structured header/list=] of [=structured header/strings=].
-
-

-To parse allowed trusted scoring signals origins given a [=header list=] |headerList|:
-
-  1. Let |parsedHeader| be the result of [=header list/getting a structured field value=]
-    given [:Ad-Auction-Allow-Trusted-Scoring-Signals-From:] and "`list`" from |headerList|.
-  1. If |parsedHeader| is null, return an empty [=list=].
-  1. Let |result| be a new [=list=] of [=origins=].
-  1. [=list/For each=] |entry| in |parsedHeader|:
-    1. If |entry| is not a [=string=], return an empty [=list=].
-    1. Let |parsedEntry| be the result of [=parsing an https origin=] on |entry|.
-    1. If |parsedEntry| is failure, return an empty [=list=].
-    1. [=list/Append=] |parsedEntry| to |result|.
-  1. Return |result|.
-

-
-

-To fetch script given a [=URL=] |url|:
-  1. Let |request| be a new [=request=] with the following properties:
-    :   [=request/URL=]
-    ::  |url|
-    :   [=request/header list=]
-    ::  «`Accept`: `text/javascript`»
-    :   [=request/client=]
-    ::  `null`
-    :   [=request/mode=]
-    ::  "`no-cors`"
-    :   [=request/referrer=]
-    :: "`no-referrer`"
-    :   [=request/credentials mode=]
-    ::  "`omit`"
-    :   [=request/redirect mode=]
-    :: "`error`"
-
-    Issue: One of the side-effects of a `null` client for this subresource request is it neuters all
-    service worker interceptions, despite not having to set the service workers mode.
-
-    Issue: Stop using "`no-cors`" mode where possible
-    (WICG/turtledove#667).
-  1. Let |script| be null.
-  1. Let |allowCrossOriginTrustedScoringSignalsFrom| be an empty [=list=].
-  1. Let |fetchController| be the result of [=fetching=] |request| with [=fetch/useParallelQueue=]
-    set to true, and [=fetch/processResponse=] set to the following steps given
-    a [=response=] |response|:
-    1. If the result of [=validating fetching response headers=] given |response| is false:
-      1. [=fetch controller/Abort=] |fetchController|.
-      1. Set |script| to failure.
-      1. Return.
-    1. Set |allowCrossOriginTrustedScoringSignalsFrom| to the result of [=parsing allowed trusted
-      scoring signals origins=] given |response|'s [=response/header list=].
-    1. Let |bodyStream| be |response|’s [=response/body=]’s [=body/stream=].
-    1. Let |bodyReader| be result of [=ReadableStream/getting a reader=] from |bodyStream|.
-    1. Let |successSteps| be a set of steps that take a [=byte sequence=] |responseBody|, and
-      perform the following:
-      1. If [=validate fetching response mime and body=] with |response|, |responseBody| and
-        "`text/javascript`" returns false, set |script| to failure.
-      1. Otherwise, set |script| to |responseBody|.
-    1. Let |failureSteps| be a set of steps that take an [=exception=] e, and
-      perform the following:
-      1. Set |script| to failure.
-    1. [=ReadableStreamDefaultReader/Read all bytes=] from |bodyReader|, given |successSteps|
-      and |failureSteps|.
-  1. Wait for |script| to be set.
-  1. Return « |script|, |allowCrossOriginTrustedScoringSignalsFrom| ».
-

-
 

 To fetch WebAssembly given a [=URL=] |url|:
 
@@ -2621,8 +2558,10 @@ To report result given a [=leading bid info=] |leadingBidInfo|, a
      given |winner|'s [=generated bid/interest group=] and |igAd| is true, then [=map/set=]
      |browserSignals|["{{ReportingBrowserSignals/buyerAndSellerReportingId}}"] to |igAd|'s
      [=interest group ad/buyer and seller reporting ID=].
-  1. Let « |sellerReportingScript|, ignored » be the result of [=fetching script=]
-    with |config|'s [=auction config/decision logic url=].
+  1. Let |sellerReportingScriptFetcher| be the result of [=creating a new script fetcher=] with
+     |config|'s [=auction config/decision logic url=].
+  1. Let |sellerReportingScript| be the result of [=waiting for script body from a fetcher=] given
+     |sellerReportingScriptFetcher|.
   1. Let « |sellerSignals|, |reportUrl|, |reportingBeaconMap|, ignored » be the result of
     [=evaluating a reporting script=] with |sellerReportingScript|, "`reportResult`", |config|'s
     [=auction config/config idl=]'s {{AuctionAdConfig/reportingTimeout}}, and
@@ -2690,8 +2629,10 @@ a {{ReportingBrowserSignals}} |browserSignals|, and a [=direct from seller signa
       |igAd|'s [=interest group ad/buyer reporting ID=].
     1. Otherwise, [=map/Set=] |reportWinBrowserSignals|["{{ReportWinBrowserSignals/interestGroupName}}"]
       to |winner|'s [=generated bid/interest group=] [=interest group/name=].
-  1. Let « |buyerReportingScript|, ignored » be the result of [=fetching script=]
-    with |winner|'s [=generated bid/interest group=]'s [=interest group/bidding url=].
+  1. Let |buyerReportingScriptFetcher| be the result of [=creating a new script fetcher=] with
+     |winner|'s [=generated bid/interest group=]'s [=interest group/bidding url=].
+  1. Let |buyerReportingScript| be the result of [=waiting for script body from a fetcher=] given
+     |buyerReportingScriptFetcher|.
   1. Let |reportFunctionName| be "`reportWin`".
   1. If |winner|'s [=generated bid/provided as additional bid=] is true:
     1. Set |reportFunctionName| be "`reportAdditionalBidWin`".
@@ -5605,6 +5546,113 @@ A per signals url bid generator is an [=ordered map=] whose [=map/key
 representing [=interest group/joining origins=], and whose [=map/values=] are [=lists=] of
 [=interest groups=].
 
+
Script fetcher

+
+A script fetcher helps manage asynchronous fetching of scripts and handling of their
+headers. It's a [=struct=] with the following [=struct/items=]:
+
+

+  : script body
+  :: A [=byte sequence=], null or failure. Initially null. The body of the script.
+  : origins authorized for cross origin trusted signals
+  :: A [=list=] of [=origins=] or null. Initially null. Parsed value of
+     [:Ad-Auction-Allow-Trusted-Scoring-Signals-From:].
+

+
+

+To create a new script fetcher given a [=URL=] |url|:
+
+  1. Let |fetcher| be a new [=script fetcher=].
+  1. Let |queue| be the result of [=starting a new parallel queue=].
+  1. [=parallel queue/enqueue steps|Enqueue the following steps=] to |queue|:
+    1. [=Fetch script=] given |url| and |fetcher|.
+  1. Return |fetcher|.
+

+
+

+To wait for script body from a fetcher given a [=script fetcher=] |fetcher|:
+
+  1. Wait until |fetcher|'s [=script fetcher/script body=] is not null.
+  1. Return |fetcher|'s [=script fetcher/script body=].
+

+
+

+To wait for cross origin trusted scoring signals authorization from a fetcher given a
+[=script fetcher=] |fetcher|:
+
+  1. Wait until |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=].
+    is not null.
+  1. Return |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=].
+

+
+The Ad-Auction-Allow-Trusted-Scoring-Signals-From HTTP response
+header is a [=structured header=] whose value must be a [=structured header/list=] of [=structured
+header/strings=].
+
+

+To parse allowed trusted scoring signals origins given a [=header list=] |headerList|:
+
+  1. Let |parsedHeader| be the result of [=header list/getting a structured field value=]
+    given [:Ad-Auction-Allow-Trusted-Scoring-Signals-From:] and "`list`" from |headerList|.
+  1. If |parsedHeader| is null, return an empty [=list=].
+  1. Let |result| be a new [=list=] of [=origins=].
+  1. [=list/For each=] |entry| in |parsedHeader|:
+    1. If |entry| is not a [=string=], return an empty [=list=].
+    1. Let |parsedEntry| be the result of [=parsing an https origin=] on |entry|.
+    1. If |parsedEntry| is failure, return an empty [=list=].
+    1. [=list/Append=] |parsedEntry| to |result|.
+  1. Return |result|.
+

+
+

+To fetch script given a [=URL=] |url| and a [=script fetcher=] |fetcher|:
+  1. Let |request| be a new [=request=] with the following properties:
+    :   [=request/URL=]
+    ::  |url|
+    :   [=request/header list=]
+    ::  «`Accept`: `text/javascript`»
+    :   [=request/client=]
+    ::  `null`
+    :   [=request/mode=]
+    ::  "`no-cors`"
+    :   [=request/referrer=]
+    :: "`no-referrer`"
+    :   [=request/credentials mode=]
+    ::  "`omit`"
+    :   [=request/redirect mode=]
+    :: "`error`"
+
+    Issue: One of the side-effects of a `null` client for this subresource request is it neuters all
+    service worker interceptions, despite not having to set the service workers mode.
+
+    Issue: Stop using "`no-cors`" mode where possible
+    (WICG/turtledove#667).
+  1. Let |fetchController| be the result of [=fetching=] |request| with [=fetch/useParallelQueue=]
+    set to true, and [=fetch/processResponse=] set to the following steps given
+    a [=response=] |response|:
+    1. If the result of [=validating fetching response headers=] given |response| is false:
+      1. [=fetch controller/Abort=] |fetchController|.
+        1. Set |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=] to
+          an empty [=list=] of [=origins=].
+        1. Set |fetcher|'s [=script fetcher/script body=] to failure.
+    1. Set |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=] to the
+      result of [=parsing allowed trusted scoring signals origins=] given |response|'s [=response/
+      header list=].
+    1. Let |bodyStream| be |response|’s [=response/body=]’s [=body/stream=].
+    1. Let |bodyReader| be result of [=ReadableStream/getting a reader=] from |bodyStream|.
+    1. Let |successSteps| be a set of steps that take a [=byte sequence=] |responseBody|, and
+      perform the following:
+      1. If [=validate fetching response mime and body=] with |response|, |responseBody| and
+        "`text/javascript`" returns false, set |fetcher|'s [=script fetcher/script body=] to
+        failure.
+      1. Otherwise, set set |fetcher|'s [=script fetcher/script body=] to |responseBody|.
+    1. Let |failureSteps| be a set of steps that take an [=exception=] e, and
+      perform the following:
+      1. Set set |fetcher|'s [=script fetcher/script body=] to failure.
+    1. [=ReadableStreamDefaultReader/Read all bytes=] from |bodyReader|, given |successSteps|
+      and |failureSteps|.
+

+
 
Trusted bidding signals batcher

 
 A trusted bidding signals batcher helps manage merging multiple trusted bidding signals

From d0fc36054a9d58cc4aec62438dc0d4720ba7c4e1 Mon Sep 17 00:00:00 2001
From: Michael Kleber 
Date: Mon, 8 Jul 2024 10:54:18 -0400
Subject: [PATCH 09/13] Create 2024-07-03-FLEDGE-call-minutes.md

---
 meetings/2024-07-03-FLEDGE-call-minutes.md | 295 +++++++++++++++++++++
 1 file changed, 295 insertions(+)
 create mode 100644 meetings/2024-07-03-FLEDGE-call-minutes.md

diff --git a/meetings/2024-07-03-FLEDGE-call-minutes.md b/meetings/2024-07-03-FLEDGE-call-minutes.md
new file mode 100644
index 000000000..5e2a44c91
--- /dev/null
+++ b/meetings/2024-07-03-FLEDGE-call-minutes.md
@@ -0,0 +1,295 @@
+# Protected Audience WICG Calls: Agenda & Notes
+
+Calls take place on most Wednesdays, at 11am US Eastern time; check [#88](https://github.com/WICG/turtledove/issues/88) for exceptions.
+
+That's 8am California = 5pm Paris time = 3pm UTC (during summer)
+
+This notes doc will be editable during the meeting — if you can only comment, hit reload
+
+Notes from past calls are all on GitHub [in this directory](https://github.com/WICG/turtledove/tree/main/meetings).
+
+
+# Next video-call meeting: Wednesday July 3, 2024 
+
+To be added to a Google Calendar invitation for this meeting, join the Google Group https://groups.google.com/a/chromium.org/g/protected-audience-api-meetings/ 
+
+If the meeting disappears from your calendar: try leaving and re-joining that group
+
+
+## Attendees: please sign yourself in!	 
+
+
+
+1. Michael Kleber (Google Privacy Sandbox)
+2. Brian May (Dstillery)
+3. Arthur Coleman (IDPrivacy)
+4. Patrick McCann (Raptive)
+5. Don Marti (Raptive)
+6. Aymeric Le Corre (Lucead)
+7. Jacob Goldman (Google Ad Manager)
+8. Sven May (Google Privacy Sandbox)
+9. Orr Bernstein (Google Privacy Sandbox)
+10. Gianni Campion (GoogleAds)
+11. Sarah Harris (Flashtalking)
+12. Owen Ridolfi (Flashtalking)
+13. Jeremy Bao (Google Privacy Sandbox)
+14. Isaac Foster (MSFT Ads)
+15. Tim Taylor (Flashtalking)
+16. Luckey Harpley (Remerge)
+17. Laura Morinigo (Samsung)
+18. David Tam (Relay42)
+19. Abishai Gray (Google Privacy Sandbox)
+20. Alex Peckham (Flashtalking)
+21. Stan Belov (Google Ad Manager)
+22. Shafir Uddin (Raptive)
+23. Matthew Atkinson (Samsung)
+24. Ken Gordon (Azure)
+25. David Dabbs (Epsilon)
+26. Koji Ota(CyberAgent)
+27. Matt Davies (Bidswitch | Criteo)
+28. Kenneth Kharma (OpenX) 
+29. Paul Spadaccini (Flashtalking)
+30. Rahul Shelat (Google Privacy Sandbox)
+31. Andrew Pascoe (NextRoll)
+32. Maybelline Boon (Google Privacy Sandbox)
+
+
+## Note taker: Arthur Coleman	
+
+
+# Agenda
+
+
+## Process reminder: Join WICG
+
+If you want to participate in the call, please make sure you join the WICG: https://www.w3.org/community/wicg/
+
+Contributions to this work are subject to W3C Community Contributor License Agreement (CLA) which can be found here: https://www.w3.org/community/about/process/cla/ 
+
+
+## Suggest agenda items here:
+
+*   Isaac Foster:
+
+    *    Trusted Scoring Signals for Financials: Via [Comment](https://github.com/WICG/turtledove/issues/824#issuecomment-2198376904) on [Roni Original](https://github.com/WICG/turtledove/issues/824) 
+
+
+    *    Brief revisit the “coarse information sharing” thing, we had talked about setting up time but never did, all got too busy…can even answer here
+
+
+    *    Multi Tag Support via “Mixed Ranking”: (really, this + multi tag + bit leak discussion and how we can be creative) https://github.com/WICG/turtledove/issues/846
+
+
+    *    Optional decouple bidding/reporting function urls to allow smaller k tuple: https://github.com/WICG/turtledove/issues/679#issuecomment-1703973736 \
+
+
+*   Gianni Campion (briefly discuss 0 ads API for joinIG  https://github.com/WICG/turtledove/issues/1191)
+
+
+*   Yao Xiao
+
+    *   discuss header api for joinIG https://github.com/WICG/turtledove/issues/82
+
+*   Jeremy Bao (Google Privacy Sandbox)
+    *   Feedback on negative interest group targeting proposal and usage budget https://github.com/WICG/turtledove/issues/896#issuecomment-2174598427
+
+
+# Announcements
+
+The Microsoft Edge folks are holding every-second-Thursday meetings at this same hour to discuss their very similar "Ad Selection API" work.  See https://github.com/WICG/privacy-preserving-ads/issues/50 for logistics.
+
+Everyone is responsible for their own comments - so go back later and make sure the notes are accurate
+
+You can even fix them on Github later!! :) 
+
+
+# Notes 
+
+
+## Isaac Foster: Trusted Scoring Signals for Financials, via [Comment](https://github.com/WICG/turtledove/issues/824#issuecomment-2198376904) on [Roni's issue 824](https://github.com/WICG/turtledove/issues/824)
+
+[Isaac] - Thinks we talked about this before around Roni’s issue - there is a challenge that we have right now with pricing trends - more than one, actually. 
+
+Ideally, folks would rather not put sensitive pricing terms into the web page.  Also a bit of a challenge with linking up with final pricing via your scoring.  What we at MSFT do today - when we receive a bid from a DSP, while we are scoring we are also applying various financial terms to the bid to determine what the final price would be.  All of which is not just a straightforward function of the bid. All of that magic happens, scoring happens, and then - you want to report out the figures you scored on.  And those figures need to be consistent - bid $1 and you pay 90 cents - preferably there is a consistency between scoring and reporting time.  Right now there is some challenge around that.  Also, the object graph of what goes into pricing can be pretty complicated.  A lot to jam into the auction config.
+
+So those are the problems.  My idea was two fold.
+
+
+
+1. Chrome piece of support
+2. Something the industry would have to do to enable this
+
+Simple version:
+
+The framework that Protected Audience Framework uses would inject into the scoring function of the seller the signals that had been sent back by the trusted scoring signals - the seller’s KV call - and those could be used along with things like creative audit to settle pricing.
+
+Then you know you are getting back the same signals back from the scoring function and reporting function.  Then you wouldn’t need to put your entire graph into the scoring config.  Then the industry would have to say there is enough information in the config of the renderURL to do the scoring/reporting.  
+
+[Michael Kleber] - Let me repeat back what you are saying.  There are two different times in the course of the Protected Audience auction where somebody gets to look up information from a trusted key value server - today your own, later the real, trusted one.  One of those times is during bidding, some data made available to the bidder in generateBid().  In that case the keys are very unrestricted.  You can put whatever you want in the keys of the interest group, then look up information from that from the trusted bidding signals server.  And that information would not be safe to make available at event level logging time because keys have no good privacy properties and so values returned from server won’t have good privacy properties either.
+
+But the other time is when a party doing the sell side and scoring - when they get to look up signals from their trusted scoring signals server- the lookup key is the render URL of any ad that is of a bid being considered or scored in the near future.  And the winning ad has this k-anonymity property associated with it.  The thrust of the ask here - since we are already letting other reporting contain the winning ad renderURL itself, then can’t we let the winning event-level report contain other information - some values looked up from the sellers from the KV server.  The contention is that there is no new privacy risk here because it is a key and if you know the key you should be able to know the value associated with that key.  More convenient to make the value used in scoring available at reporting time because it prevents items from unexpectedly changing in the meantime, which could happen if you update the server at the wrong moment.
+
+Do I have that correct?
+
+[Isaac] Yes.
+
+[Stan Belov].  I understand the proposal from the API standpoint.  I need to understand better how we would use it.  In this case, are you thinking about some sort of pricing decisions that are specific to individual ad creatives?  There’s another question, but explain this first.
+
+[Isaac]  It would require both a feature on the Chrome side and then the buyer/seller have to agree on the protocol.  Let’s stick to the idea it is fully in the renderURL for now.  Today, in our exchange, we may apply different contract terms, fees, bid ups vs. bid downs - things like that - depending on advertiser and publisher and deal specifics.  If that information is encoded in the renderURL - the IDs that the buyer and seller have agreed upon- then when that went to get looked up in the trusted scoring signals call.  The seller could have indexed whatever from the combination of parameters - it is bid up, rev share, private  marketplace etc.  That then goes back into the scoreAd and the report itself since those two things can actually share code.  You can have a common function and send common parameters into that common function.  That should be roughly guaranteed to be consistent data between the two.  You don’t have to put your pricing terms through the private auction config which is a little bit less secure,  It seems a little better to me
+
+[Brian May] When you say data and consistent logic, you mean between the buyer and seller?
+
+[Isaac] I meant between score time vs. report result time.  Score time vs recording of financials from the transaction time.  So like today when we do our stuff around the auction, we log all that immediately.  That process that is scored says ‘here are the financials’.  Hypothetically, if we put that in a report result, we don’t have a way to put all that complex information in.  Or the data may have changed.  We scored on V1.01 and we reported on V1.02 - or contracts changed
+
+[Stan] Sounds like you are proposing to encode financial information that may affect pricing in the renderURL.  And one of the major use cases here could be to deal with some sort of agreement between a buyer and a publisher - correct?  I was wondering if you have looked at some other threads on the same topic of deal support.  I just want to make sure by looking at this use case to make sure you know pricing terms that need to be accessed in the reporting and need to be accessed in scoreAd.  But they themselves are not reflecting the actual creative.  Can these concepts be split apart in some way?  From an exchange perspective, there is a need to duplicate a renderURL, for each combination of potential deals, attributes related to classification,etc.
+
+[Isaac] Have read #873 before, so I do think we should maintain the decoupling of renderURL from important reporting information. So I did put something in the comment like the initial proposal - the renderURL - would we factor in some of the buyer and seller reporting ID things that still have the k-anonymity properties that will help us maintain the healthy decoupling.  There is a second cut of this we need to specify better.
+
+The additional piece for Chrome would be in addition to the renderURL going through on the trusted scoring signals call, it would also be the buyer and seller reporting ID, which should be ok if we can agree on the k-anonymity restriction.  Which we have already agreed in other contexts is needed. So I think we can maintain that decoupling and still get something useful.
+
+[Stan]  I think the use of the buyer and seller reporting IDs and trusted scoring signals needs to be clear. 
+
+I think the idea of propagating scoring signals to the reporting function is also quite valuable, especially if you want to ensure that the promises made to the publishers are fulfilled.  Let’s say the creatives that don’t satisfy the requirements were indeed filtered.  Maybe a publisher excludes certain categories, for example.  That way synchronization between score time and reporting time are the same is very valuable. 
+
+[Michael] Not surprised that this also turns into a request for the buyer and seller reporting (deal) ID to become a part of what is sent to the the seller’s trusted server - I think that is already there in your comment Isaac.  I anticipated that would be part of the request.
+
+Again, I agree that this does not seem like a dramatic change to the privacy stance, because all this information you want included in the event level report that you can look up after receiving the event-level report - except for the synchronization issue.  That seems ok even if a design change that addresses an edge case.  Not too burdensome.
+
+From a privacy point of view, the seller's trusted scoring signals server is receiving multiple bids at the same time. As long as we are in BYOS, then that is obviously a new privacy leakage because it is possible the values returned by the TSS server could be based not just on the renderURL but all the other renderURLS as well which might include a unique user ID.  If you are running your own server, you could use this to include a user ID in the event logs.  
+
+If you are using BYOS and you do decide to cheat, then you can just log the user ID in your log server side.  It is not like putting them in the event level report is  a dramatic change in terms of level of harm, but let’s be clear we are giving away a mechanic to put user ID in the event level report.  That’s not something we want to do.  Requires migrating to a secure server running inside a TEE that have limits on how computation works.
+
+[Isaac] Want to make sure I am clear.  It's not that there is a new privacy leak, it's that it exposes the leak in an additional place.
+
+[Michael] I mostly agree.  There is already a privacy leak if your server wants to cheat in logging stuff you could find a way to log user ID in some way based on all bids sent to your server.
+
+[Isaac] Then you would have something you produced from all renderURLs in the same place as your auction config.  
+
+[Michael]  It is definitely an opportunity for the event level report to include a new privacy risk that it does not include today
+
+[Isaac] Yes, I agree, there is marginally more information.
+
+[Michael] I will have to talk to some other folks on the team to see how this marginal privacy risk stacks up with other things.  Only makes me slightly uncomfortable - only because it is related to BYOS for now.  If your goal were to cheat by violating what a trusted server is supposed to do, then doing it by returning data back through the browser and into the win report  is a much more visible and discoverable way of cheating.  Versus doing it server side which is an invisible and non-discoverable way of cheating.  I think this is a tolerable privacy risk as a result.
+
+[Stan] From the privacy perspective, in today's environment the trusted scoring signals server can see a combination of information about all the ads and bids plus the top-level domain.  Where here the potential delta would be the combination of all contextual information that is available in the report.  This could include some proxy for a user ID, correct?
+
+[Isaac] What I was thinking, I think you could do it such that you would do it in such a way that you get an ID in a renderURL that may not pass k-anonymity, but that doesn’t matter, and put this in your process on your BYOS key value server.  Does make it a bit easier, but not fundamentally different
+
+[Stan] I would argue something different.  I think that the argument is that the incremental risk is the combination of the contextual information that is available in the report
+
+[Isaac] Yes you can do that in the BYOS scenario
+
+[Stan] A good question if the BYOS trusted scoring signals are required to be k-anonymous or something else.
+
+[Isaac] I’d have to check.  The renderURL is only judged after the key value call?  Michael?
+
+[Michael] - I think that is right.  We have to talk about it with some folks not on the call. But it's not so big that I think it should not keep us from doing this.  Both Isaac and Stan - it sounds like you think there is value.  Any other points of view?  Good discussion and we understand the goals.  Tied to request to send buyer and seller reporting ID to Key Value Server and the whole deal support work going on.
+
+
+## Gianni Campion (briefly discuss 0 ads API for joinIG), https://github.com/WICG/turtledove/issues/1191
+
+[Gianni] - I think there was a Github discussion about what we would like to do regarding having a lightweight joinAdInterestGroup().  The idea is that the first daily update is going to update most of the stuff anyway.  Our plan is to join the lightweight joinAdInterestGroup() across the response so you have a skeleton of information to send the device for how you set up an ID.  Then we can rely on the first daily update to fill in the blanks needed for the interest group to perform its duties.  Proposal is to have a field that is triggered on the first update with a certain delay.  Most of the discussion seems to revolve around Brian May’s comment about the failure of the first update.  So I didn’t look too much in detail, but if you think about it, let’s say you have an API that says _trigger this daily update in 10 seconds_ and the network fails, we would still have what exists now - an update that fixes it after the first auction.  It becomes a quality issue related to how much do you lose between the first joinAdInterestGroup() and the first update.
+
+[Michael] I think this is reasonable.  We talked about once before in the context of supporting the lightweight interest group joining from the HTTP response header.  So not have to have a Javascript element on the page to do this but instead use a JavaScript response header.  This seems like a good idea to me - lightweight join and call soon afterwards with JavaScript response header.  Seems like we should do this - no promises about priorities - a fine future element to do.
+
+[Gianni] So what are the next steps?
+
+[Michael]  Us to get around to doing it.
+
+[David Dabbs] Question for Gianni.  Is your pattern of use - Isaac brought this up - he wanted to reduce the number of updates in a series of page-to-page-to page - this doesn’t get rid of that - which is fine. It is up to the caller to do that.
+
+[Gianni] What is the pattern you are mentioning?
+
+[David] Where you are going to drop and join interest groups.  And instead of rendering the full interest group, in your approach you render a minimum and then 10 seconds later you still have to go back to an updateURL()  to fill out the interest group later.  
+
+If you want to reduce the number of those update calls, that’s up to the caller to do that.  This is just getting it off the main line of rendering on the page - make it lighter.
+
+[Gianni] Yes.  And you probably delete that after the update.  If the same interest group gets called multiple times - maybe that interest group should be updated only once. So for this group, fire only one update for them.
+
+[David] Netting it out: _We do it after the user has left the site over time_ - might be more than we can expect from Chrome. It can probably guarantee doing something when the page/frame ceases to exist (kind of like _fetchLater_) but probably not beyond that. 
+
+[Michael] A good thing to be concerned about here.  Gianni - I would like the interest group to update itself soon, not once a day, for example.  There has to be a minimal amount of time between updates - now it is 10 minutes - so we don’t overrun the browser.  If you try to do this join and get an update immediately, and you try to do it for each page, then it seems like it is good to include in this request what behavior you hope for.  I assume you are asking for an update when the user is on the same page where they were adding to the interest group.
+
+[Gianni] Not necessarily while on the same page, would be ok to happen a little later
+
+[Michael] But you are not asking for Chrome to deliberately wait until after the user has left this page, right?  I don’t want you to be disappointed when a user goes to six different pages in a row, you don’t get an update on every page.
+
+[Brian] I suggest we set a flag that when someone calls joinAdInterestGroup().  Let’s say I want to add this interest group, the call is made but if the flag is set a certain way, then don't have me add the same information over and over.
+
+[David] In other words, it should silently fail.
+
+[Brian] Yes.  If I do the same things 5 in a row, only do it once and ignore the other times.
+
+[Michael] If you do a minimal join for an interest group already there on the browser, then you probably don’t want to overwrite all the information on every page.  So there is some complexity.
+
+[Gianni] My desire, let’s take the example of example.com - we set my IG join to delay one minute - in that one minute I visit 6 pages that have an interest group, call it Interest Group 10.  I queue up six daily updates as a result.  Not a good idea to do all six - so only do the last one?  We need to agree on a mechanism here.
+
+So I keep adding this lightweight thing, and the heavy lifting occurs with the one daily update.  So the last update should count.  I think that my preferred behavior is to use the last one, since if we were doing all the updates the last one would be the final state.
+
+[Brian] We should be very careful about how we are thinking about the application of this.  If we produce this capability, then what people will do is they will create 100s of lightweight interest groups, wait for them to update, and then try to monetize them in the future.  
+
+[Gianni]  How is that different?  It is already doable.  The API only allows you to not miss the first daily update
+
+[Michael] I don’t think there is any new marginal interest group creation capability here that people can’t do today.  That risk exists today.  This new capability would make it just as easy to create a bunch of interest groups except you would double the load on your server because you’d have to add a second call a few minutes later.
+
+[Brian] Let me push back on that.  If I can create an interest group by popping minimal information into a header and then blasting a bunch of those headers down into the browser, then I will do a lot more interest group creation and then later update - so more likely to have it happen.  It takes a lot more effort to create a number of interest groups today.
+
+[David] No it doesn't take much more effort.  You just have to wait and lose a couple of auctions on the page. By the time the user goes and leaves the page, you have a couple of double or triple taps on auctions where Chrome hasn’t loaded you up.  Now the update occurs and you have a fully operational interest group.   And then you have a similar problem.
+
+[Brian] If the pattern is I create shell interest groups vs. fully-functional interest groups that can be immediately used, I will create many more shells because they are easy to create.
+
+[Michael] The point is that to create a shell and turn into a real interest group - the space between those two operations is a few seconds, so you are not reducing the work really because in a few seconds you have to do the full update anyway.  The difference in workload in the two scenarios does not seem enough to me to change people’s likely behavior.
+
+[Brian] If I can create light groups and coordinate quickly only with myself now, I’ll do that more likely.
+
+[Gianni] You wouldn’t be able to do it now, for example by returning an interest group that only has a daily update - no keys and no ads.   WIthin that automatic, it is literally something you can do now if you have implemented the update function.  If your update function updates the keys… (interrupted) \
+
+
+[Brian]  Not suggesting we shouldn’t do this, but we need to be aware of how people might use it.
+
+[Michael] The only marginal change Gianni is asking for is to update this newly created interest group in a few seconds rather than waiting for the 10 minutes that is the current minimum update functionality. It would get updated in the first auction.  So I don’t bother waiting for this interest group to be invited to be in an auction.
+
+Yao - this  seems related to what you asked about in your agenda item (shown below)
+
+
+    **Yao Xiao**
+
+
+        ** discuss header api for joinIG https://github.com/WICG/turtledove/issues/82**
+
+[Yao] Thank you.  Basically what happens today - the way tagging works -  on the advertiser side we inject the iFrame and the server side returns a second response.   Inside this second response we have the joinAdInterestGroup API getting invoked. In this way we can join the interest group and store it in the browser.   But there are performance issues around iFrames and, equally, we have to make sure the tag supports the joinAdInterestGroup() API, which is a JavaScript API.  But there are companies/users that don’t want to support a JavaScript API, they want a header-based solution instead.  We have already done something like this for attribution reporting API and shared storage API.   If we are going to move to the header-based approach above, we want to provide header-based support for all three endpoints - joinAdInterestGroup, leaveAdInterestGroup(), and ClearOriginJoinedAdInterestGroups(). 
+
+[Michael] This is exactly the kind of support that would make this Gianni ask into a useful thing.  Aligned with prior discussion.
+
+[David] So to the original request, you (Michael/Chrome) agree this ask is reasonable and useful, but can’t provide commitment/timing. Revising my earlier request for Chrome to provide a recognised means to ‘crowdsource’ your stakeholders’ interest to guide your dev priorities.
+
+[Michael] Github is the way to do that right now.  Our PMs try to take in info from the various sources and trying to prioritize based on what they are hearing from the market. 
+
+[Arthur Coleman] David, you asked this a while ago.  My company has built a community site for Protected Audience, I just did the roadmap for it.  Let's talk offline.  Happy to pull something together, with Alex and other Google folks.  I agree that it's needed, we should have a way for the community to thumbs up/down and help prioritization.
+
+[David] WICG repos now have the _Discussions_ feature available.  That's a possible option here, where we already review issues. 
+
+[Brian] Is there value in people placing a “thumbs-up” on issues?
+
+[Michael] People writing something in a github issue is better than thumbs up.  Much more informative
+
+[David] Yao, are you looking for a way to express an _entire_ interest group in a structured header or just a portion?  
+
+[Michael] Let me point out there are limits to the lengths of HTTP headers. 
+
+[Notetakers note for reader’s reference: Each individual header (name and value combined) has a maximum length of approximately 4096 bytes. This limit ensures compatibility with various network protocols and prevents excessively large headers from causing issues.  The total size of all request and response headers combined has a limit of approximately 250 KB.]
+
+[Michael] The only way we could do a good job of supporting that without putting a limit on interest groups is to do the lightweight approach.  A flag that says I would like to update this interest group as soon as possible and some limit in the HTTP header for what parameters you could set.
+
+[David] Yes, in the issue we outlined a specific attribute set for this “shell” pattern.
+
+[Brian] You may want to create multiple interest groups for one owner at one time.
+
+[Isaac] Ability to create interest groups via header - doing the light shell with refresh would be highly valued.  Publishers are always hesitant to add JS to their page.
+
+[Michael] 100% our motivation for doing the header approach.
+
+
+## [Jeremy Bao] - Solution for negative interest groups
+
+We didn’t get to cover that today.  Several requests around that and we are creating a proposal around that.  I see several folks on the call related to that proposal - please take a look at it.  Github Issue [#896](https://github.com/WICG/turtledove/issues/896).

From 38d3b021e61de2623de269b282142febd5880a23 Mon Sep 17 00:00:00 2001
From: Maks Orlovich 
Date: Thu, 11 Jul 2024 10:46:55 -0400
Subject: [PATCH 10/13] Explainer for cross-origin trusted signals (#1156)

Spec in https://github.com/WICG/turtledove/pull/1197
---
 FLEDGE.md               | 90 +++++++++++++++++++++++++++++++++++++++--
 PA_Feature_Detecting.md | 42 ++++++++++++++++++-
 2 files changed, 127 insertions(+), 5 deletions(-)

diff --git a/FLEDGE.md b/FLEDGE.md
index 1125b6c42..5d9cc7650 100644
--- a/FLEDGE.md
+++ b/FLEDGE.md
@@ -28,6 +28,7 @@ See [the Protected Audience API specification](https://wicg.github.io/turtledove
       - [2.5.2 Using Response Headers](#252-using-response-headers)
   - [3. Buyers Provide Ads and Bidding Functions (BYOS for now)](#3-buyers-provide-ads-and-bidding-functions-byos-for-now)
     - [3.1 Fetching Real-Time Data from a Trusted Server](#31-fetching-real-time-data-from-a-trusted-server)
+      - [3.1.1 Cross-Origin Trusted Server Signals](#311-cross-origin-trusted-server-signals)
     - [3.2 On-Device Bidding](#32-on-device-bidding)
     - [3.3 Metadata with the Ad Bid](#33-metadata-with-the-ad-bid)
     - [3.4 Ads Composed of Multiple Pieces](#34-ads-composed-of-multiple-pieces)
@@ -505,7 +506,7 @@ Once the bids are known, the seller runs code inside an _auction worklet_.  With
 
 ```
 scoreAd(adMetadata, bid, auctionConfig, trustedScoringSignals, browserSignals,
-    directFromSellerSignals) {
+    directFromSellerSignals, crossOriginTrustedSignals) {
   ...
   return {desirability: desirabilityScoreForThisAd,
           incomingBidInSellerCurrency:
@@ -520,7 +521,7 @@ The function gets called once for each candidate ad in the auction.  The argumen
 *   adMetadata: Arbitrary metadata provided by the buyer.
 *   bid: A numerical bid value.
 *   auctionConfig: The auction configuration object passed to `navigator.runAdAuction()`.
-*   trustedScoringSignals: A value retrieved from a real-time trusted server chosen by the seller and reflecting the seller's opinion of this particular creative, as further described in [3.1 Fetching Real-Time Data from a Trusted Server](#31-fetching-real-time-data-from-a-trusted-server) below.  (In the case of [ads composed of multiple pieces](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#34-ads-composed-of-multiple-pieces) this should instead be some collection of values, structure TBD.)
+*   trustedScoringSignals: A value retrieved from a real-time trusted server chosen by the seller and reflecting the seller's opinion of this particular creative, as further described in [3.1 Fetching Real-Time Data from a Trusted Server](#31-fetching-real-time-data-from-a-trusted-server) below. This is used when the server is same-origin to the seller; crossOriginTrustedSignals is used otherwise.
 *   browserSignals: An object constructed by the browser, containing information that the browser knows and which the seller's auction script might want to verify:
     ```
     { 'topWindowHostname': 'www.example-publisher.com',
@@ -538,6 +539,11 @@ The function gets called once for each candidate ad in the auction.  The argumen
 *   directFromSellerSignals is an object that may contain the following fields:
     *   sellerSignals: Like auctionConfig.sellerSignals, but passed via the [directFromSellerSignals](#25-additional-trusted-signals-directfromsellersignals) mechanism. These are the signals whose subresource URL ends in `?sellerSignals`.
     *   auctionSignals: Like auctionConfig.auctionSignals, but passed via the [directFromSellerSignals](#25-additional-trusted-signals-directfromsellersignals) mechanism. These are the signals whose subresource URL ends in `?auctionSignals`.
+*   crossOriginTrustedSignals: like `trustedScoringSignals`, but used when the server is cross-origin
+    to the seller script. The value is an object that has as a key the trusted server's origin, e.g.
+    `"https://example.org"`, and as value an object in format `trustedScoringSignals` uses. See
+    [3.1.1 Cross-Origin Trusted Server Signals](#311-cross-origin-trusted-server-signals) for more
+    details.
 
 The output of `scoreAd()` is an object with the following fields:
 * desirability: Number indicating how desirable this ad is.  Any value that is zero or negative indicates that the ad cannot win the auction.  (This could be used, for example, to eliminate any interest-group-targeted ad that would not beat a contextually-targeted candidate.) The winner of the auction is the ad object which was given the highest score.
@@ -765,6 +771,75 @@ For detailed specification and explainers of the trusted key-value server, see a
 - [FLEDGE Key/Value Server APIs Explainer](https://github.com/WICG/turtledove/blob/master/FLEDGE_Key_Value_Server_API.md)
 - [FLEDGE Key/Value Server Trust Model Explainer](https://github.com/privacysandbox/fledge-docs/blob/main/key_value_service_trust_model.md)
 
+##### 3.1.1 Cross-Origin Trusted Server Signals
+
+If the key-value server is on a different origin than the corresponding script, additional steps are
+needed to ensure that sensitive information is not inappropriately leaked to, or is manipulated by,
+a third party.
+
+In the case of bidder signals, the following changes occur:
+1. The fetch is a cross-origin [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) fetch
+   with `Origin:` set to the buyer script's origin.
+2. The value is passed to `crossOriginTrustedSignals` parameter, not the `trustedBiddingSignals`
+   parameter, and there is one more level of nesting denoting the server's origin, e.g:
+
+```
+{
+  'https://www.kv-server.example': {
+    'keys': {
+        'key1': arbitrary_json,
+        'key2': arbitrary_json,
+        ...},
+    'perInterestGroupData': {
+        'name1': {
+            'priorityVector': {
+                'signal1': number,
+                'signal2': number,
+                ...}
+        },
+        ...
+    }
+  }
+}
+```
+3. The data version is passed in `browserSignals.crossOriginDataVersion`, not
+   `browserSignals.dataVersion`.
+
+Seller signals have additional requirements, as the `trustedScoringSignalsURL` is provided by a
+context that is not required to be same-origin with the seller:
+1. The seller script must provide an `Ad-Auction-Allow-Trusted-Scoring-Signals-From` response header,
+   a  [structured headers list of strings](https://www.rfc-editor.org/rfc/rfc8941) describing origins
+   from which fetching trusted signals is permitted. The trusted scoring signals fetch may not begin
+   until this header is received, in order to avoid leaking bid information to a third party.
+   This means using a cross-origin trusted server for seller information may carry a peformance
+   penalty.
+2. The fetch is a cross-origin [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) fetch
+   with `Origin:` set to the seller script's origin.
+3. The value is passed to `crossOriginTrustedSignals` parameter, not the `trustedScoringSignals`
+   parameter, and there is one more level of nesting denoting the server's origin, e.g:
+
+```
+{
+  'https://www.kv-server.example': {
+    'renderURL': {'https://cdn.com/render_url_of_bidder': arbitrary_value_from_signals},
+    'adComponentRenderURLs': {
+        'https://cdn.com/ad_component_of_a_bid': arbitrary_value_from_signals,
+        'https://cdn.com/another_ad_component_of_a_bid': arbitrary_value_from_signals,
+        ...}
+  }
+}
+```
+4. The data version is passed in `browserSignals.crossOriginDataVersion`, not
+   `browserSignals.dataVersion`.
+
+Note that older versions of Chrome did not support cross-origin trusted signals. You can query
+whether support is available as:
+
+```
+navigator.protectedAudience && navigator.protectedAudience.queryFeatureSupport(
+    "permitCrossOriginTrustedSignals")
+```
+
 #### 3.2 On-Device Bidding
 
 Once the trusted bidding signals are fetched, each interest group's bidding function will run, inside a bidding worklet associated with the interest group owner's domain.  The buyer's JavaScript is loaded from the interest group's `biddingLogicURL`, which must expose a `generateBid()` function:
@@ -772,7 +847,8 @@ Once the trusted bidding signals are fetched, each interest group's bidding func
 
 ```
 generateBid(interestGroup, auctionSignals, perBuyerSignals,
-    trustedBiddingSignals, browserSignals, directFromSellerSignals) {
+    trustedBiddingSignals, browserSignals, directFromSellerSignals,
+    crossOriginTrustedSignals) {
   ...
   return {'ad': adObject,
           'adCost': optionalAdCost,
@@ -797,7 +873,7 @@ The arguments to `generateBid()` are:
     * `priority` and `prioritySignalsOverrides` are not included. They can be modified by `generatedBid()` calls, so could theoretically be used to create a cross-site profile of a user accessible to `generateBid()` methods, otherwise.
 *   auctionSignals: As provided by the seller in the call to `runAdAuction()`.  This is the opportunity for the seller to provide information about the page context (ad size, publisher ID, etc), the type of auction (first-price vs second-price), and so on.
 *   perBuyerSignals: The value for _this specific buyer_ as taken from the auction config passed to `runAdAuction()`.  This can include contextual signals about the page that come from the buyer's server, if the seller is an SSP which performs a real-time bidding call to buyer servers and pipes the response back, or if the publisher page contacts the buyer's server directly.  If so, the buyer may wish to check a cryptographic signature of those signals inside `generateBid()` as protection against tampering.
-*   trustedBiddingSignals: An object whose keys are the `trustedBiddingSignalsKeys` for the interest group, and whose values are those returned in the `trustedBiddingSignals` request.
+*   trustedBiddingSignals: An object whose keys are the `trustedBiddingSignalsKeys` for the interest group, and whose values are those returned in the `trustedBiddingSignals` request. This used when the trusted server is same-origin with the buyer's script.
 *   browserSignals: An object constructed by the browser, containing information that the browser knows, and which the buyer's auction script might want to use or verify.  The `dataVersion` field will only be present if the `Data-Version` header was provided and had a consistent value for all of the trusted bidding signals server responses used to construct the trustedBiddingSignals. `topLevelSeller` is only present if `generateBid()` is running as part of a component auction. Additional fields can include information about both the context (e.g. the true hostname of the current page, which the seller could otherwise lie about) and about the interest group itself (e.g. times when it previously won the auction, to allow on-device frequency capping). Note that unlike for `reportWin()` the `joinCount` and `recency` in `generateBid()`'s browser signals *isn't* subject to the [noising and bucketing scheme](#521-noised-and-bucketed-signals). Furthermore, `recency` in `generateBid()`'s browser signals is specified in milliseconds, rounded to the nearest 100 milliseconds.
     ```
     { 'topWindowHostname': 'www.example-publisher.com',
@@ -820,6 +896,12 @@ The arguments to `generateBid()` are:
 *   directFromSellerSignals is an object that may contain the following fields:
     *   perBuyerSignals: Like auctionConfig.perBuyerSignals, but passed via the [directFromSellerSignals](#25-additional-trusted-signals-directfromsellersignals) mechanism. These are the signals whose subresource URL ends in `?perBuyerSignals=[origin]`.
     *   auctionSignals: Like auctionConfig.auctionSignals, but passed via the [directFromSellerSignals](#25-additional-trusted-signals-directfromsellersignals) mechanism. These are the signals whose subresource URL ends in `?auctionSignals`.
+*   crossOriginTrustedSignals: Like `trustedBiddingSignals`, but used when the trusted-server is
+    cross-origin to the buyer's script. The value is an object that has as a key the trusted
+    server's origin, e.g. `"https://www.kv-server.example"`, and as value an object in format
+    `trustedBiddingSignals` uses. See
+    [3.1.1 Cross-Origin Trusted Server Signals](#311-cross-origin-trusted-server-signals) for more
+    details.
 
 In the case of component auctions, an interest group's `generateBid()` function will be invoked in all component auctions for which it qualifies, though the `bidCount` value passed to future auctions will only be incremented by one for participation in that auction as a whole.
 
diff --git a/PA_Feature_Detecting.md b/PA_Feature_Detecting.md
index d4bf0874f..50e62b0a0 100644
--- a/PA_Feature_Detecting.md
+++ b/PA_Feature_Detecting.md
@@ -70,7 +70,7 @@ beacon, and then the ad frame can set the same automatic beacon data for both ev
 `top_navigation_commit` and `top_navigation` beacons, and filter out duplicate beacons that have the same exact data.
 
 ## Increase in limit to number of component ads
-[Intent to Ship](TBD)
+[Intent to Ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/3RUQk0GCC9Q/m/wmbXOOB8AAAJ)
 
 Inside `generateBid` one can determine the currently active limit on number of components ads as follows:
 ```
@@ -106,6 +106,7 @@ const reportingTimeoutEnabled = navigator.protectedAudience ?
 ```
 
 ## Returning multiple bids from generateBid()
+[Intent to Ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdZXN1D-MtI/)
 
 Inside `generateBid()`, if `browserSignals.multiBidLimit` exists then returning
 an array of bids is supported. The value of `browserSignals.multiBidLimit`
@@ -113,7 +114,46 @@ returns the maximum numbers of bids that can be returned, which may be as low as
 1.
 
 ## Component ad subsetting with targetNumAdComponents
+[Intent to Ship](https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdZXN1D-MtI/)
 
 Inside `generateBid()`, if `browserSignals.multiBidLimit` exist then
 the `targetNumAdComponents` and `numMandatoryAdComponents` bid fields will be
 considered.
+
+## Cross-origin trusted signals
+[Intent to Ship](TBD)
+
+From context of a web page:
+```
+navigator.protectedAudience && navigator.protectedAudience.queryFeatureSupport(
+    "permitCrossOriginTrustedSignals")
+```
+
+## Getting browser-side detectable features as an object
+Sometimes it's desirable to get status of all features detectable via `queryFeatureSupport` in a
+forward-compatible way. Sufficiently recent versions provide this functionality via
+`queryFeatureSupport('*')`, which returns a dictionary describing state of various features. Since
+that functionality isn't available in older versions, backwards-compatibility polyfilling is
+suggested:
+
+```
+let qfs = navigator.protectedAudience ?
+    navigator.protectedAudience.queryFeatureSupport.bind(navigator.protectedAudience) : null;
+
+let allFeatureStatus = qfs ?
+  (qfs("*") || {
+    adComponentsLimit: qfs("adComponentsLimit"),
+    deprecatedRenderURLReplacements: qfs("deprecatedRenderURLReplacements"),
+    reportingTimeout: qfs("reportingTimeout")
+   }) : {}
+```
+
+An example return value would be:
+```
+{
+  "adComponentsLimit":40,
+  "deprecatedRenderURLReplacements":false,
+  "reportingTimeout":true,
+  "permitCrossOriginTrustedSignals":true
+}
+```

From 585f660f929ab7474e939ffcb16edf5037b4b980 Mon Sep 17 00:00:00 2001
From: Maks Orlovich 
Date: Thu, 11 Jul 2024 10:47:48 -0400
Subject: [PATCH 11/13] Specify support for cross-origin trusted signals
 (#1197)

* Specify support for cross-origin trusted signals,
and the bundled queryFeatureSupport('*'). This also includes
fixes to some bugs in parsing of these URLs (some of the
checks were missing).
---
 spec.bs | 415 +++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 273 insertions(+), 142 deletions(-)

diff --git a/spec.bs b/spec.bs
index 7f4e68941..f6270059c 100644
--- a/spec.bs
+++ b/spec.bs
@@ -58,7 +58,8 @@ spec: RFC8941; urlPrefix: https://httpwg.org/specs/rfc8941.html
     for: structured header
       text: boolean; url: boolean
       text: integer; url: integer
-      text: boolean; url: boolean
+      text: list; url: list
+      text: string; url: string
 spec: WebAssembly; urlPrefix: https://webassembly.github.io/spec/core/
   type: dfn
     urlPrefix: appendix/embedding.html
@@ -310,21 +311,17 @@ This is detectable because it can change the set of fields that are read from th
         "{{GenerateBidInterestGroup/updateURL}}"
         [=interest group/update url=]
       
-      
-        "{{GenerateBidInterestGroup/trustedBiddingSignalsURL}}"
-        [=interest group/trusted bidding signals url=]
-      
     
     1. If |group| [=map/contains=] |groupMember|:
-      1. Let |parsedUrl| be the result of running the [=URL parser=] on |group|[|groupMember|].
-      1. [=exception/Throw=] a {{TypeError}} if any of the following conditions hold:
-        * |parsedUrl| is failure;
-        * |parsedUrl| is not [=same origin=] with |interestGroup|'s [=interest group/owner=];
-        * |parsedUrl| [=includes credentials=];
-        * |parsedUrl| [=url/fragment=] is not null.
+      1. Let |parsedUrl| be the result of running [=parse and verify a bidding code or update URL=]
+        on |group|[|groupMember|] and |interestGroup|'s [=interest group/owner=].
+      1. If |parsedUrl| is failure, then [=exception/throw=] a {{TypeError}}.
       1. Set |interestGroup|'s |interestGroupField| to |parsedUrl|.
-  1. If |interestGroup|'s [=interest group/trusted bidding signals url=]'s [=url/query=] is not
-    null, then [=exception/throw=] a {{TypeError}}.
+  1. If |group|["{{GenerateBidInterestGroup/trustedBiddingSignalsURL}}"] [=map/exists=]:
+    1. Let |parsedUrl| be the result of running [=parse and verify a trusted signals URL=] on
+      |group|[{{GenerateBidInterestGroup/trustedBiddingSignalsURL}}].
+    1. If |parsedUrl| is failure, then [=exception/throw=] a {{TypeError}}.
+    1. Set |interestGroup|'s [=interest group/trusted bidding signals url=] to |parsedUrl|.
   1. If |group|["{{GenerateBidInterestGroup/trustedBiddingSignalsKeys}}"] [=map/exists=], then set
     |interestGroup|'s [=interest group/trusted bidding signals keys=] to
     |group|["{{GenerateBidInterestGroup/trustedBiddingSignalsKeys}}"].
@@ -1068,11 +1065,9 @@ To validate and convert auction ad config given an {{AuctionAdConfig}
   [=auction config/seller=], then return failure.
 1. Set |auctionConfig|'s [=auction config/decision logic url=] to |decisionLogicURL|.
 1. If |config|["{{AuctionAdConfig/trustedScoringSignalsURL}}"] [=map/exists=]:
-  1. Let |trustedScoringSignalsURL| be the result of running the [=URL parser=] on
+  1. Let |trustedScoringSignalsURL| be the result of [=parse and verify a trusted signals URL=] on
     |config|["{{AuctionAdConfig/trustedScoringSignalsURL}}"].
-  1. If |trustedScoringSignalsURL| is failure, or it is not [=same origin=] with |auctionConfig|'s
-    [=auction config/seller=], then return failure.
-  1. [=Assert=]: |trustedScoringSignalsURL|'s [=url/scheme=] is "`https`".
+  1. If |trustedScoringSignalsURL| is failure, return failure.
   1. Set |auctionConfig|'s [=auction config/trusted scoring signals url=] to
     |trustedScoringSignalsURL|.
 1. If |config|["{{AuctionAdConfig/maxTrustedScoringSignalsURLLength}}"] [=map/exists=]:
@@ -1470,7 +1465,8 @@ To check if required seller capabilities are permitted given an [=auc
 
 

 
-To generate potentially multiple bids given an [=ordered map=]-or-null |allTrustedBiddingSignals|,
+To generate potentially multiple bids given an [=ordered map=]-or-null
+|allTrustedBiddingSignals|, and an [=origin=]-or-null |crossOriginTrustedBiddingSignalsOrigin|,
 a [=string=] |auctionSignals|, a {{BiddingBrowserSignals}} |browserSignals|, a [=string=]-or-null |perBuyerSignals|,
 a {{DirectFromSellerSignalsForBuyer}} |directFromSellerSignalsForBuyer|, a [=duration=]
 |perBuyerTimeout| in milliseconds, a [=currency tag=] |expectedCurrency|, an {{unsigned short}}
@@ -1497,8 +1493,8 @@ a {{DirectFromSellerSignalsForBuyer}} |directFromSellerSignalsForBuyer|, a [=dur
     1. [=map/Set=] |prevWinIDL|["{{PreviousWin/adJSON}}"] to |prevWin|'s [=previous win/ad json=].
     1. [=list/Append=] |prevWinIDL| to |prevWins|.
   1. [=map/Set=] |browserSignals|["{{BiddingBrowserSignals/prevWinsMs}}"] to |prevWins|.
-  1. Let |biddingScript| be the result of [=fetching script=] with |ig|'s
-    [=interest group/bidding url=].
+  1. Let « |biddingScript|, ignored » be the result of [=fetching script=] with
+    |ig|'s [=interest group/bidding url=].
   1. If |biddingScript| is failure, return failure.
   1. If |ig|'s [=interest group/bidding wasm helper url=] is not null:
     1. Let |wasmModuleObject| be the result of [=fetching WebAssembly=] with |ig|'s
@@ -1513,9 +1509,21 @@ a {{DirectFromSellerSignalsForBuyer}} |directFromSellerSignalsForBuyer|, a [=dur
     1. [=list/For each=] |key| of |ig|'s [=interest group/trusted bidding signals keys=]:
       1. If |allTrustedBiddingSignals|[|key|] [=map/exists=], then [=map/set=]
         |trustedBiddingSignals|[|key|] to |allTrustedBiddingSignals|[|key|].
+  1. Let |sameOriginTrustedBiddingSignals| be null.
+  1. Let |crossOriginTrustedBiddingSignals| be null.
+  1. If |trustedBiddingSignals| is not null:
+    1. If |crossOriginTrustedBiddingSignalsOrigin| is null, then set
+      |sameOriginTrustedBiddingSignals| to |trustedBiddingSignals|.
+    1. Otherwise:
+      1. Set |crossOriginTrustedBiddingSignals| to a new [=ordered map=] whose [=map/keys=] are
+          [=strings=] and whose [=map/values=] are {{any}}.
+      1. Let |originKey| be the [=serialization of an origin|serialization=] of
+          |crossOriginTrustedBiddingSignalsOrigin|.
+      1. [=map/Set=] |crossOriginTrustedBiddingSignalsOrigin|[|originKey|] to |trustedBiddingSignals|.
   1. Return the result of [=evaluating a bidding script=] with |biddingScript|, |multiBidLimit|, |ig|, |expectedCurrency|,
-    |igGenerateBid|, |auctionSignals|, |perBuyerSignals|, |trustedBiddingSignals|, |browserSignals|,
-    |directFromSellerSignalsForBuyer|, and |perBuyerTimeout|.
+    |igGenerateBid|, |auctionSignals|, |perBuyerSignals|, |sameOriginTrustedBiddingSignals|,
+    |crossOriginTrustedBiddingSignals|, |browserSignals|, |directFromSellerSignalsForBuyer|.
+    and |perBuyerTimeout|.
 

 
 

@@ -1526,8 +1534,8 @@ To generate and score bids given an [=auction config=] |auctionConfig
 |bidDebugReportInfoList|:
 1. [=Assert=] that these steps are running [=in parallel=].
 1. Let |auctionStartTime| be the [=current wall time=].
-1. Let |decisionLogicScript| be the result of [=fetching script=] with |auctionConfig|'s
-  [=auction config/decision logic url=].
+1. Let « |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom| » be the result of
+  [=fetching script=] with |auctionConfig|'s [=auction config/decision logic url=].
 1. If |decisionLogicScript| is failure, return null.
 1. Let |seller| be |auctionConfig|'s [=auction config/seller=].
 1. Let « |bidGenerators|, |negativeTargetInfo| » be the result of running
@@ -1559,12 +1567,12 @@ To generate and score bids given an [=auction config=] |auctionConfig
     1. If |compWinnerInfo|'s [=leading bid info/leading bid=] is not null, then run
       [=score and rank a bid=] with |auctionConfig|, |compWinnerInfo|'s
       [=leading bid info/leading bid=], |leadingBidInfo|, |decisionLogicScript|,
-      null, "top-level-auction", null, and |topLevelOrigin|.
+      |allowCrossOriginTrustedScoringSignalsFrom|, null, "top-level-auction", null, and |topLevelOrigin|.
     1. If |compWinnerInfo|'s [=leading bid info/leading non-k-anon-enforced bid=]
       is not null, then run [=score and rank a bid=] with |auctionConfig|,
       |compWinnerInfo|'s [=leading bid info/leading non-k-anon-enforced bid=],
-      |leadingBidInfo|, |decisionLogicScript|, null, "top-level-auction", null,
-      and |topLevelOrigin|.
+      |leadingBidInfo|, |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom|, null,
+      "top-level-auction", null, and |topLevelOrigin|.
     1. Decrement |pendingComponentAuctions| by 1.
   1. Wait until |pendingComponentAuctions| is 0.
   1. If |leadingBidInfo|'s [=leading bid info/leading bid=] is null, return null.
@@ -1630,8 +1638,8 @@ To generate and score bids given an [=auction config=] |auctionConfig
 1. Let |pendingAdditionalBids| be the [=list/size=] of |additionalBids|.
 1. [=list/For each=] |additionalBid| of |additionalBids|, run the following steps [=in parallel=]:
   1. [=Score and rank a bid=] with |auctionConfig|, |additionalBid|, |leadingBidInfo|,
-    |decisionLogicScript|, null, |auctionLevel|, |componentAuctionExpectedCurrency|, and
-    |topLevelOrigin|.
+    |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom|, null, |auctionLevel|,
+    |componentAuctionExpectedCurrency|, and |topLevelOrigin|.
   1. Decrement |pendingAdditionalBids| by 1.
 1. Let |settings| be |global|'s [=relevant settings object=].
 1. [=map/For each=] |buyer| → |perBuyerGenerator| of |bidGenerators|,
@@ -1680,6 +1688,9 @@ To generate and score bids given an [=auction config=] |auctionConfig
     to the result of running [=is debugging only in cooldown or lockout=] with |buyer|.
   1. [=map/For each=] |slotSizeQueryParam| → |perSlotSizeQueryParam| of |perBuyerGenerator|:
     1. [=map/For each=] |signalsUrl| → |perSignalsUrlGenerator| of |perSlotSizeQueryParam|:
+      1. Let |crossOriginTrustedBiddingSignalsOrigin| be null.
+      1. If |buyer| is not [=same origin=] with |signalsUrl|'s [=url/origin=], then set
+        |crossOriginTrustedBiddingSignalsOrigin| to |signalsUrl|'s [=url/origin=].
       1. Let |trustedBiddingSignalsBatcher| be a new [=trusted bidding signals batcher=].
       1. Let |fetchSignalStartTime| be |settings|'s [=environment settings object/current monotonic time=].
       1. [=map/For each=] joiningOrigin → |groups| of |perSignalsUrlGenerator|:
@@ -1687,7 +1698,7 @@ To generate and score bids given an [=auction config=] |auctionConfig
           1. [=Batch or fetch trusted bidding signals=] given |trustedBiddingSignalsBatcher|,
             |ig|, |signalsUrl|, |buyerExperimentGroupId|, |topLevelOrigin|, and |slotSizeQueryParam|.
         1. [=Fetch the current outstanding trusted signals batch=] given |trustedBiddingSignalsBatcher|,
-            |signalsUrl|, |buyerExperimentGroupId|, |topLevelOrigin|, and |slotSizeQueryParam|.
+            |signalsUrl|, |buyer|, |buyerExperimentGroupId|, |topLevelOrigin|, and |slotSizeQueryParam|.
       1. [=Process updateIfOlderThanMs=] with |buyer|, and |trustedBiddingSignalsBatcher|'s
          [=trusted bidding signals batcher/all per interest group data=].
       1. Let |fetchSignalDuration| be the [=duration from=] |fetchSignalStartTime| to |settings|'s
@@ -1712,11 +1723,17 @@ To generate and score bids given an [=auction config=] |auctionConfig
             1. Set |dataVersion| to |trustedBiddingSignalsBatcher|'s [=trusted bidding signals batcher/data versions=]
                [|ig|'s [=interest group/name=]].
             1. Set |allTrustedBiddingSignals| to [=trusted bidding signals batcher/all trusted bidding signals=].
-          1. If |dataVersion| is not null, then [=map/set=] |browserSignals|["{{BiddingBrowserSignals/dataVersion}}"] to |dataVersion|.
-          1. Otherwise, [=map/remove=] |browserSignals|["{{BiddingBrowserSignals/dataVersion}}"].
+          1. [=map/Remove=] |browserSignals|["{{BiddingBrowserSignals/dataVersion}}"].
+          1. [=map/Remove=] |browserSignals|["{{BiddingBrowserSignals/crossOriginDataVersion}}"].
+          1. If |dataVersion| is not null:
+            1. If |crossOriginTrustedBiddingSignalsOrigin| is not null, then [=map/set=]
+               |browserSignals|["{{BiddingBrowserSignals/crossOriginDataVersion}}"] to |dataVersion|.
+            1. Otherwise, [=map/set=] |browserSignals|["{{BiddingBrowserSignals/dataVersion}}"] to
+               |dataVersion|.
           1. Let « |bidsBatch|, |bidDebugReportInfo| » be the result of [=generate potentially multiple bids=] given
-            |allTrustedBiddingSignals|, |auctionSignals|, a [=map/clone=] of |browserSignals|,
-            |perBuyerSignals|, |directFromSellerSignalsForBuyer|, |perBuyerTimeout|,
+            |allTrustedBiddingSignals|, |crossOriginTrustedBiddingSignalsOrigin|, |auctionSignals|,
+            a [=map/clone=] of |browserSignals|, |perBuyerSignals|,
+            |directFromSellerSignalsForBuyer|, |perBuyerTimeout|,
             |expectedCurrency|, |multiBidLimit|, |ig|, and |auctionStartTime|.
           1. Let |generateBidDuration| be the [=duration from=] |generateBidStartTime| to |settings|'s
             [=environment settings object/current monotonic time=], in milliseconds.
@@ -1755,7 +1772,8 @@ To generate and score bids given an [=auction config=] |auctionConfig
             1. Let |generateBidStartTime| be |settings|'s
               [=environment settings object/current monotonic time=].
             1. Set « |generatedBids|, |bidDebugReportInfo| » to the result of [=generate potentially multiple bids=] given
-              |allTrustedBiddingSignals|, |auctionSignals|, a [=map/clone=] of |browserSignals|,
+              |allTrustedBiddingSignals|, |crossOriginTrustedBiddingSignalsOrigin|, |auctionSignals|,
+              a [=map/clone=] of |browserSignals|,
               |perBuyerSignals|, |directFromSellerSignalsForBuyer|, |perBuyerTimeout|, |expectedCurrency|,
               1 (for multiBidLimit), |ig|, and |auctionStartTime|.
 
@@ -1778,7 +1796,8 @@ To generate and score bids given an [=auction config=] |auctionConfig
             1. If |bidToScore|'s [=generated bid/for k-anon auction=] is true,
                 [=list/append=] |bidToScore|'s [=generated bid/interest group=] to |bidIgs|.
             1. [=Score and rank a bid=] with |auctionConfig|, |bidToScore|, |leadingBidInfo|,
-              |decisionLogicScript|, |directFromSellerSignalsForSeller|, |dataVersion|, |auctionLevel|,
+              |decisionLogicScript|, |allowCrossOriginTrustedScoringSignalsFrom|,
+              |directFromSellerSignalsForSeller|, |dataVersion|, |auctionLevel|,
               |componentAuctionExpectedCurrency|, and |topLevelOrigin|.
   1. Decrement |pendingBuyers| by 1.
 1. Wait until both |pendingBuyers| and |pendingAdditionalBids| are 0.
@@ -1863,55 +1882,96 @@ To convert to an AuctionAd sequence given a [=list=]-or-null |ads|:
 

 
 

-To score and rank a bid given an [=auction config=] |auctionConfig|, a [=generated bid=]
-|generatedBid|, a [=bid debug reporting info=] |bidDebugReportInfo|, a [=leading bid info=] |leadingBidInfo|, a [=string=] |decisionLogicScript|, a
-{{DirectFromSellerSignalsForSeller}} |directFromSellerSignalsForSeller|, an {{unsigned long}}-or-null
-|biddingDataVersion|, an enum |auctionLevel|, which is "single-level-auction", "top-level-auction",
-or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, and an [=origin=]
-|topLevelOrigin|:
-
+To fetch and decode trusted scoring signals given an [=auction config=] |auctionConfig|,
+a [=generated bid=] |generatedBid|, a [=list=] of [=origins=]
+|allowCrossOriginTrustedScoringSignalsFrom|, and an [=origin=] |topLevelOrigin|:
+
+1. Let |crossOriginTrustedScoringSignalsOrigin| be null.
+1. Let |sameOriginTrustedScoringSignals| be null.
+1. Let |crossOriginTrustedScoringSignals| be null.
+1. Let |scoringDataVersion| be null.
 1. Let |renderURL| be [=URL serializer|serialized=] |generatedBid|'s
   [=generated bid/ad descriptor=]'s [=ad descriptor/url=].
 1. Let |adComponentRenderURLs| be a new empty [=list=].
 1. If |generatedBid|'s [=generated bid/ad component descriptors=] is not null:
-  1. [=list/For each=] |adComponentDescriptor| in |generatedBid|'s
-    [=generated bid/ad component descriptors=]:
+  1. [=list/For each=] |adComponentDescriptor| in |generatedBid|'s [=generated bid/ad component
+    descriptors=]:
     1. [=list/Append=] [=URL serializer|serialized=] |adComponentDescriptor|'s [=ad descriptor/url=]
       to |adComponentRenderURLs|.
-1. Let |fullSignalsUrl| be the result of [=building trusted scoring signals url=] with |auctionConfig|'s
-  [=auction config/trusted scoring signals url=], «|renderURL|», |adComponentRenderURLs|,
-  |auctionConfig|'s [=auction config/seller experiment group id=], and |topLevelOrigin|.
-
-  Implementations may batch requests by collecting render URLs and ad component render URLs
-  from multiple invocations of [=score and rank a bid=] and passing them all to a single invocation
-  of [=building trusted scoring signals url=] to get a |scoringSignalsUrl|. By employing this approach,
-  the [=string/length=] of [=URL serializer|serialized=] |scoringSignalsUrl| must not exceed the
-
-  [=auction config/max trusted scoring signals url length=] of the auction. In cases where the length
-  limit is exceeded, the request must be divided into smaller pieces to comply with the length restriction.
-  However, note that a single request is always considered valid, regardless of whether its length exceeds
-  the auction's [=auction config/max trusted scoring signals url length=].
-
-
-  The network response has to be parsed to pull out the pieces relevant to each
-  [=evaluating a scoring script|evaluation of a scoring script=].
-1. Let |trustedScoringSignals| be null.
-1. Let «|allTrustedScoringSignals|, ignored, |scoringDataVersion|» be the result of [=fetching
-  trusted signals=] with |fullSignalsUrl| and false.
-1. If |allTrustedScoringSignals| is an [=ordered map=]:
-  1. Set |trustedScoringSignals| to a new empty [=map=].
-  1. [=map/Set=] |trustedScoringSignals|["`renderURL`"] to a new empty [=map=].
-  1. If |allTrustedScoringSignals|["`renderURLs`"] [=map/exists=] and
-    |allTrustedScoringSignals|["`renderURLs`"][|renderURL|] [=map/exists=], then [=map/set=] |trustedScoringSignals|["`renderURL`"][|renderURL|] to
-    |allTrustedScoringSignals|["`renderURLs`"][|renderURL|].
-  1. If |adComponentRenderURLs| is not [=list/empty=]:
-    1. Let |adComponentRenderURLsValue| be a new empty [=map=].
-    1. If |allTrustedScoringSignals|["`adComponentRenderURLs`"] [=map/exists=], [=set/for each=]
-      |adComponentRenderURL| in |adComponentRenderURLs|:
-      1. If |allTrustedScoringSignals|["`adComponentRenderURLs`"][|adComponentRenderURL|]
-        [=map/exists=], then [=map/set=] |adComponentRenderURLsValue|[|adComponentRenderURL|] to
-        |allTrustedScoringSignals|["`adComponentRenderURLs`"][|adComponentRenderURL|].
-    1. [=map/Set=] |trustedScoringSignals|["`adComponentRenderURLs`"] to |adComponentRenderURLsValue|.
+1. Let |fullSignalsUrl| be null.
+1. If |auctionConfig|'s [=auction config/trusted scoring signals url=] is not null:
+  1. Set |fullSignalsUrl| be the result of [=building trusted scoring signals url=] with |auctionConfig|'s
+    [=auction config/trusted scoring signals url=], «|renderURL|», |adComponentRenderURLs|,
+    |auctionConfig|'s [=auction config/seller experiment group id=], and |topLevelOrigin|.
+
+    Implementations may batch trusted scoring signals
+    requests with same [=auction config/trusted scoring signals url=], |auctionConfig|'s
+    [=auction config/seller experiment group id=], and |topLevelOrigin| by collecting render URLs
+    and ad component render URLs from multiple invocations of [=score and rank a bid=] and passing
+    them all to a single invocation of [=building trusted scoring signals url=] to get a
+    |scoringSignalsUrl|. Requests may not be combined if the resulting combination's
+    [=string/length=] of [=URL serializer|serialized=] |scoringSignalsUrl| exceeds the [=auction
+    config/max trusted scoring signals url length=] of the auction; however this limit does not
+    apply if no combining has taken place.
+
+    The network response has to be parsed to pull out the pieces relevant to each
+    [=evaluating a scoring script|evaluation of a scoring script=].
+
+    These requests may also begin before the script fetch, but requests cross-origin to the
+    script origin must not happen until [:Ad-Auction-Allow-Trusted-Scoring-Signals-From:] header on
+    the script is received, parsed, and determined to authorize such a fetch.
+  1. If |fullSignalsUrl|'s [=url/origin=] is not [=same origin=] with |auctionConfig|'s
+     [=auction config/seller=], then:
+      1. Set |crossOriginTrustedScoringSignalsOrigin| to |fullSignalsUrl|'s [=url/origin=].
+      1. If |allowCrossOriginTrustedScoringSignalsFrom| does not [=list/contain=]
+        |crossOriginTrustedScoringSignalsOrigin|:
+        1. Set |crossOriginTrustedScoringSignalsOrigin| to null.
+        1. Set |fullSignalsUrl| to null.
+1. If |fullSignalsUrl| is not null:
+  1. Let |allTrustedScoringSignals| be null.
+  1. Set «|allTrustedScoringSignals|,
+    ignored, |scoringDataVersion|» to the result of [=fetching trusted signals=]
+    with |fullSignalsUrl|, |auctionConfig|'s [=auction config/seller=], and false.
+  1. If |allTrustedScoringSignals| is an [=ordered map=]:
+    1. Let |trustedScoringSignals| be a new empty [=map=].
+    1. [=map/Set=] |trustedScoringSignals|["`renderURL`"] to a new empty [=map=].
+    1. If |allTrustedScoringSignals|["`renderURLs`"] [=map/exists=] and
+      |allTrustedScoringSignals|["`renderURLs`"][|renderURL|] [=map/exists=], then [=map/set=]
+      |trustedScoringSignals|["`renderURL`"][|renderURL|] to
+      |allTrustedScoringSignals|["`renderURLs`"][|renderURL|].
+    1. If |adComponentRenderURLs| is not [=list/empty=]:
+      1. Let |adComponentRenderURLsValue| be a new empty [=map=].
+      1. If |allTrustedScoringSignals|["`adComponentRenderURLs`"] [=map/exists=], [=set/for each=]
+        |adComponentRenderURL| in |adComponentRenderURLs|:
+        1. If |allTrustedScoringSignals|["`adComponentRenderURLs`"][|adComponentRenderURL|]
+          [=map/exists=], then [=map/set=] |adComponentRenderURLsValue|[|adComponentRenderURL|] to
+          |allTrustedScoringSignals|["`adComponentRenderURLs`"][|adComponentRenderURL|].
+      1. [=map/Set=] |trustedScoringSignals|["`adComponentRenderURLs`"] to |adComponentRenderURLsValue|.
+    1. If |crossOriginTrustedScoringSignalsOrigin| is null, set |sameOriginTrustedScoringSignals|
+      to |trustedScoringSignals|.
+    1. Otherwise:
+      1. Set |crossOriginTrustedScoringSignals| to a new [=map=].
+      1. Let |originKey| be the [=serialization of an origin|serialization=] given
+          |crossOriginTrustedScoringSignalsOrigin|.
+      1. [=map/Set=] |crossOriginTrustedScoringSignals|[|originKey|] to |trustedScoringSignals|.
+1. Return «|crossOriginTrustedScoringSignalsOrigin|, |sameOriginTrustedScoringSignals|,
+    |crossOriginTrustedScoringSignals|, |scoringDataVersion|»
+
+

+
+

+To score and rank a bid given an [=auction config=] |auctionConfig|, a [=generated bid=]
+|generatedBid|, a [=bid debug reporting info=] |bidDebugReportInfo|, a [=leading bid info=] |leadingBidInfo|,
+a [=string=] |decisionLogicScript|, a [=list=] or [=origins=] |allowCrossOriginTrustedScoringSignalsFrom|,
+a {{DirectFromSellerSignalsForSeller}} |directFromSellerSignalsForSeller|, an {{unsigned long}}-or-null
+|biddingDataVersion|, an enum |auctionLevel|, which is "single-level-auction", "top-level-auction",
+or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, and an [=origin=]
+|topLevelOrigin|:
+
+1. Let «|crossOriginTrustedScoringSignalsOrigin|, |sameOriginTrustedScoringSignals|,
+  |crossOriginTrustedScoringSignals|, |scoringDataVersion|» be the result of [=fetch and
+  decode trusted scoring signals=] given |auctionConfig|, |generatedBid|,
+  |allowCrossOriginTrustedScoringSignalsFrom|, |topLevelOrigin|.
 1. Let |adMetadata| be |generatedBid|'s [=generated bid/ad=].
 1. Let |bidValue| be |generatedBid|'s [=generated bid/bid=].
 1. If |generatedBid|'s [=generated bid/modified bid=] is not null, then set |bidValue| to
@@ -1936,7 +1996,11 @@ or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, a
     
The result of [=serializing a currency tag=] with |generatedBid|'s [=generated bid/bid=]'s
       [=bid with currency/currency=]
     
{{ScoringBrowserSignals/dataVersion}}
-    
|scoringDataVersion| if it is not null, {{undefined}} otherwise
+    
|scoringDataVersion| if it is not null and |crossOriginTrustedScoringSignalsOrigin| is null,
+        unset otherwise.
+    
{{ScoringBrowserSignals/crossOriginDataVersion}}
+    
|scoringDataVersion| if it is not null and |crossOriginTrustedScoringSignalsOrigin| is not
+        null, unset otherwise.
     
{{ScoringBrowserSignals/adComponents}}
     
|generatedBid|'s [=generated bid/ad component descriptors=] [=converted to a string sequence=]
     
{{ScoringBrowserSignals/forDebuggingOnlyInCooldownOrLockout}}
@@ -1946,8 +2010,8 @@ or "component-auction", a [=currency tag=] |componentAuctionExpectedCurrency|, a
 1. Let « |scoreAdResult|, |debugWinReportUrl|, |debugLossReportUrl| » be the result of
   [=evaluating a scoring script=] with |decisionLogicScript|, |adMetadata|,
   |bidValue|'s [=bid with currency/value=], |auctionConfig|'s [=auction config/config idl=],
-  |trustedScoringSignals|, |browserSignals|, |directFromSellerSignalsForSeller|, and
-  |auctionConfig|'s [=auction config/seller timeout=].
+  |sameOriginTrustedScoringSignals|, |crossOriginTrustedScoringSignals|, |browserSignals|,
+  |directFromSellerSignalsForSeller|, and |auctionConfig|'s [=auction config/seller timeout=].
 1. If |auctionLevel| is "top-level-auction":
   1. Set |bidDebugReportInfo|'s [=bid debug reporting info/top level seller debug loss report url=] to
     |debugLossReportUrl|.
@@ -2123,6 +2187,24 @@ To validate fetching response given a [=response=] |response|, null,
   1. Return true.
 

 
+The Ad-Auction-Allow-Trusted-Scoring-Signals-From HTTP response header is a
+[=structured header=] whose value must be a [=structured header/list=] of [=structured header/strings=].
+
+

+To parse allowed trusted scoring signals origins given a [=header list=] |headerList|:
+
+  1. Let |parsedHeader| be the result of [=header list/getting a structured field value=]
+    given [:Ad-Auction-Allow-Trusted-Scoring-Signals-From:] and "`list`" from |headerList|.
+  1. If |parsedHeader| is null, return an empty [=list=].
+  1. Let |result| be a new [=list=] of [=origins=].
+  1. [=list/For each=] |entry| in |parsedHeader|:
+    1. If |entry| is not a [=string=], return an empty [=list=].
+    1. Let |parsedEntry| be the result of [=parsing an https origin=] on |entry|.
+    1. If |parsedEntry| is failure, return an empty [=list=].
+    1. [=list/Append=] |parsedEntry| to |result|.
+  1. Return |result|.
+

+
 

 To fetch script given a [=URL=] |url|:
   1. Let |request| be a new [=request=] with the following properties:
@@ -2147,14 +2229,30 @@ To fetch script given a [=URL=] |url|:
     Issue: Stop using "`no-cors`" mode where possible
     (WICG/turtledove#667).
   1. Let |script| be null.
-  1. [=Fetch=] |request| with [=fetch/useParallelQueue=] set to true, and
-    [=fetch/processResponseConsumeBody=] set to the following steps given a [=response=] |response|
-    and null, failure, or a [=byte sequence=] |responseBody|:
-    1. If [=validate fetching response=] with |response|, |responseBody| and "`text/javascript`"
-      returns false, set |script| to failure and return.
-    1. Set |script| to |responseBody|.
+  1. Let |allowCrossOriginTrustedScoringSignalsFrom| be an empty [=list=].
+  1. Let |fetchController| be the result of [=fetching=] |request| with [=fetch/useParallelQueue=]
+    set to true, and [=fetch/processResponse=] set to the following steps given
+    a [=response=] |response|:
+    1. If the result of [=validating fetching response headers=] given |response| is false:
+      1. [=fetch controller/Abort=] |fetchController|.
+      1. Set |script| to failure.
+      1. Return.
+    1. Set |allowCrossOriginTrustedScoringSignalsFrom| to the result of [=parsing allowed trusted
+      scoring signals origins=] given |response|'s [=response/header list=].
+    1. Let |bodyStream| be |response|’s [=response/body=]’s [=body/stream=].
+    1. Let |bodyReader| be result of [=ReadableStream/getting a reader=] from |bodyStream|.
+    1. Let |successSteps| be a set of steps that take a [=byte sequence=] |responseBody|, and
+      perform the following:
+      1. If [=validate fetching response mime and body=] with |response|, |responseBody| and
+        "`text/javascript`" returns false, set |script| to failure.
+      1. Otherwise, set |script| to |responseBody|.
+    1. Let |failureSteps| be a set of steps that take an [=exception=] e, and
+      perform the following:
+      1. Set |script| to failure.
+    1. [=ReadableStreamDefaultReader/Read all bytes=] from |bodyReader|, given |successSteps|
+      and |failureSteps|.
   1. Wait for |script| to be set.
-  1. Return |script|.
+  1. Return « |script|, |allowCrossOriginTrustedScoringSignalsFrom| ».
 

 
 

@@ -2199,17 +2297,20 @@ The X-fledge-bidding-signals-format-version
 is a [=structured header=] whose value must be an [=structured header/integer=].
 
 

-To fetch trusted signals given a [=URL=] |url|, and a [=boolean=] |isBiddingSignal|:
+To fetch trusted signals given a [=URL=] |url|, an [=origin=] |scriptOrigin|,
+and a [=boolean=] |isBiddingSignal|:
 
   1. Let |request| be a new [=request=] with the following properties:
     :   [=request/URL=]
     ::  |url|
+    :   [=request/origin=]
+    ::  |scriptOrigin|
     :   [=request/header list=]
     ::  «`Accept`: `application/json`»
     :   [=request/client=]
     ::  `null`
     :   [=request/mode=]
-    ::  "`no-cors`"
+    ::  "`cors`"
     :   [=request/referrer=]
     :: "`no-referrer`"
     :   [=request/credentials mode=]
@@ -2220,8 +2321,6 @@ To fetch trusted signals given a [=URL=] |url|, and a [=boolean=] |is
     Issue: One of the side-effects of a `null` client for this subresource request is it neuters all
     service worker interceptions, despite not having to set the service workers mode.
 
-    Issue: Stop using "`no-cors`" mode where possible
-    (WICG/turtledove#667).
   1. Let |signals| be null.
   1. Let |dataVersion| be null.
   1. Let |formatVersion| be null.
@@ -2529,8 +2628,8 @@ To report result given a [=leading bid info=] |leadingBidInfo|, a
      given |winner|'s [=generated bid/interest group=] and |igAd| is true, then [=map/set=]
      |browserSignals|["{{ReportingBrowserSignals/buyerAndSellerReportingId}}"] to |igAd|'s
      [=interest group ad/buyer and seller reporting ID=].
-  1. Let |sellerReportingScript| be the result of [=fetching script=] with |config|'s
-    [=auction config/decision logic url=].
+  1. Let « |sellerReportingScript|, ignored » be the result of [=fetching script=]
+    with |config|'s [=auction config/decision logic url=].
   1. Let « |sellerSignals|, |reportUrl|, |reportingBeaconMap|, ignored » be the result of
     [=evaluating a reporting script=] with |sellerReportingScript|, "`reportResult`", |config|'s
     [=auction config/config idl=]'s {{AuctionAdConfig/reportingTimeout}}, and
@@ -2598,8 +2697,8 @@ a {{ReportingBrowserSignals}} |browserSignals|, and a [=direct from seller signa
       |igAd|'s [=interest group ad/buyer reporting ID=].
     1. Otherwise, [=map/Set=] |reportWinBrowserSignals|["{{ReportWinBrowserSignals/interestGroupName}}"]
       to |winner|'s [=generated bid/interest group=] [=interest group/name=].
-  1. Let |buyerReportingScript| be the result of [=fetching script=] with |winner|'s
-    [=generated bid/interest group=]'s [=interest group/bidding url=].
+  1. Let « |buyerReportingScript|, ignored » be the result of [=fetching script=]
+    with |winner|'s [=generated bid/interest group=]'s [=interest group/bidding url=].
   1. Let |reportFunctionName| be "`reportWin`".
   1. If |winner|'s [=generated bid/provided as additional bid=] is true:
     1. Set |reportFunctionName| be "`reportAdditionalBidWin`".
@@ -3491,9 +3590,9 @@ of the following global objects:
   |multiBidLimit|, an [=interest group=] |ig|, a [=currency tag=] |expectedCurrency|,
   a {{GenerateBidInterestGroup}} |igGenerateBid|, a [=string=]-or-null
   |auctionSignals|, a [=string=]-or-null |perBuyerSignals|, an [=ordered map=]-or-null
-  |trustedBiddingSignals|, a {{BiddingBrowserSignals}} |browserSignals|,
-  a {{DirectFromSellerSignalsForBuyer}} |directFromSellerSignalsForBuyer| and an integer millisecond
-  [=duration=] |timeout|:
+  |sameOriginTrustedBiddingSignals|, an [=ordered map=]-or-null |crossOriginTrustedBiddingSignals|,
+  a {{BiddingBrowserSignals}} |browserSignals|, a {{DirectFromSellerSignalsForBuyer}}
+  |directFromSellerSignalsForBuyer|, and an integer millisecond [=duration=] |timeout|:
 
     1. Let |realm| be the result of [=creating a new script runner realm=] given
       {{InterestGroupBiddingScriptRunnerGlobalScope}}.
@@ -3518,14 +3617,18 @@ of the following global objects:
       |auctionSignals| if |auctionSignals| is not null, otherwise {{undefined}}.
     1. Let |perBuyerSignalsJS| be the result of [=parsing a JSON string to a JavaScript value=]
       given |perBuyerSignals| if |perBuyerSignals| is not null, otherwise {{undefined}}.
-    1. Let |trustedBiddingSignalsJS| be |trustedBiddingSignals| [=converted to ECMAScript values=].
+    1. Let |sameOriginTrustedBiddingSignalsJS| be |sameOriginTrustedBiddingSignals|
+       [=converted to ECMAScript values=].
     1. Let |browserSignalsJS| be |browserSignals| [=converted to ECMAScript values=].
-    1. Let |directFromSellerSignalsJs| be |directFromSellerSignalsForBuyer|
+    1. Let |directFromSellerSignalsJS| be |directFromSellerSignalsForBuyer|
       [=converted to ECMAScript values=].
+    1. Let |crossOriginTrustedBiddingSignalsJS| be |crossOriginTrustedBiddingSignals|
+       [=converted to ECMAScript values=].
     1. Let |startTime| be |settings|'s [=environment settings object/current monotonic time=].
     1. Let |result| be the result of [=evaluating a script=] with |realm|, |script|, "`generateBid`",
-      « |igJS|, |auctionSignalsJS|, |perBuyerSignalsJS|, |trustedBiddingSignalsJS|, |browserSignalsJS|,
-      |directFromSellerSignalsJs| », and |timeout|.
+      « |igJS|, |auctionSignalsJS|, |perBuyerSignalsJS|, |sameOriginTrustedBiddingSignalsJS|,
+        |browserSignalsJS|, |directFromSellerSignalsJS|, |crossOriginTrustedBiddingSignalsJS| »,
+        and |timeout|.
     1. Let |duration| be |settings|'s [=environment settings object/current monotonic time=] minus
       |startTime| in milliseconds.
     1. If |global|'s [=InterestGroupBiddingScriptRunnerGlobalScope/priority=] is not null and not failure:
@@ -3572,21 +3675,25 @@ of the following global objects:
 
 

   To evaluate a scoring script given a [=string=] |script|, a [=string=] |adMetadata|,
-  a {{double}} |bidValue|, an {{AuctionAdConfig}} |auctionConfigIDL|, an [=ordered map=]
-  |trustedScoringSignals|, a {{ScoringBrowserSignals}} |browserSignals|, a
-  {{DirectFromSellerSignalsForSeller}} |directFromSellerSignalsForSeller|, and an integer
-  millisecond [=duration=] |timeout|:
+  a {{double}} |bidValue|, an {{AuctionAdConfig}} |auctionConfigIDL|, an [=ordered map=]-or-null
+  |sameOriginTrustedScoringSignals|, an [=ordered map=]-or-null |crossOriginTrustedScoringSignals|,
+  {{ScoringBrowserSignals}} |browserSignals|, a {{DirectFromSellerSignalsForSeller}}
+  |directFromSellerSignalsForSeller|, and an integer millisecond [=duration=] |timeout|:
 
     1. Let |realm| be the result of [=creating a new script runner realm=] given
       {{InterestGroupScoringScriptRunnerGlobalScope}}.
     1. Let |browserSignalsJS| be |browserSignals| [=converted to ECMAScript values=].
     1. Let |auctionConfigJS| be |auctionConfigIDL| [=converted to ECMAScript values=].
-    1. Let |trustedScoringSignalsJS| be |trustedScoringSignals| [=converted to ECMAScript values=].
+    1. Let |sameOriginTrustedScoringSignalsJS| be |sameOriginTrustedScoringSignals|
+       [=converted to ECMAScript values=].
+    1. Let |crossOriginTrustedScoringSignalsJS| be |crossOriginTrustedScoringSignals|
+       [=converted to ECMAScript values=].
     1. Let |directFromSellerSignalsJs| be |directFromSellerSignalsForSeller|
       [=converted to ECMAScript values=].
     1. Let |scoreAdResult| be the result of [=evaluating a script=] with |realm|, |script|, "`scoreAd`",
-      «|adMetadata|, |bidValue|, |auctionConfigJS|, |trustedScoringSignalsJS|, |browserSignalsJS|,
-      |directFromSellerSignalsJs|», and |timeout|.
+      «|adMetadata|, |bidValue|, |auctionConfigJS|, |sameOriginTrustedScoringSignalsJS|,
+      |browserSignalsJS|, |directFromSellerSignalsJs|, |crossOriginTrustedScoringSignalsJS|»,
+      and |timeout|.
     1. Let |debugWinReportUrl| be |global|'s
       [=InterestGroupBiddingAndScoringScriptRunnerGlobalScope/debug win report url=] if it's not
       failure, null otherwise.
@@ -4259,9 +4366,8 @@ navigating to another page. Some implementations, such as Chromium, have chosen
         
"`biddingLogicURL`"
         
"`biddingWasmHelperURL`"
         
"`updateURL`"
-        
"`trustedBiddingSignalsURL`"
         

-        1. For each |groupMember| and |interestGroupField| in the following table
+        1. For each |groupMember| and |interestGroupField|, in the following table
           
@@ -4276,21 +4382,22 @@ navigating to another page. Some implementations, such as Chromium, have chosen
               
-            
-              
-              
-            

             
Group memberInterest group field

             
"`updateURL`"
               [=interest group/update url=]
             
"`trustedBiddingSignalsURL`"[=interest group/trusted bidding signals url=]

           

-          1. Let |parsedURL| be the result of running the [=URL parser=] on |value|.
           1. If |key| is not |groupMember|, [=iteration/continue=].
-          1. Jump to the step labeled Abort update
-            if any of the following conditions hold:
-            * |parsedURL| is failure;
-            * |parsedURL|'s [=url/origin=] is not [=same origin=] with |ig|'s
-              [=interest group/owner=];
-            * |parsedURL| [=includes credentials=];
-            * |parsedURL| [=url/fragment=] is not null.
-          1. Set |ig|'s |interestGroupField| to |parsedURL|.
+          1. If |value| is a [=string=]:
+            1. Let |parsedURL| be the result of [=parse and verify a bidding code or update URL=]
+              on |value| and |ig|'s [=interest group/owner=].
+            1. If |parsedURL| is failure, jump to the step labeled 
+              Abort update
+            1. Set |ig|'s |interestGroupField| to |parsedURL|.
+
+        
"`trustedBiddingSignalsURL`"

+        

+          1. If |value| is a [=string=]:
+            1. Let |parsedURL| be the result of [=parse and verify a trusted signals URL=] on |value|.
+            1. If |parsedURL| is failure, jump to the step labeled 
+              Abort update
+            1. Set |ig|'s [=interest group/trusted bidding signals url=] to |parsedURL|.
 
         
"`trustedBiddingSignalsKeys`"
         

@@ -4436,8 +4543,11 @@ The queryFeatureSupport(feature) method
     ::  40
     :   "deprecatedRenderURLReplacements"
     :: true
+    :   "permitCrossOriginTrustedSignals"
+    :: true
     :   "reportingTimeout"
     :: true
+1. If |feature| is "*", then return |featuresTable|.
 1. If |featuresTable|[|feature|] [=map/exists=], then return |featuresTable|[|feature|].
 1. Return `undefined`.
 
@@ -4522,6 +4632,33 @@ The estimated size of an [=interest group=] |ig|
     1. Return the [=URL serializer|serialization=] of |url|.
 

 
+

+  To parse and verify a bidding code or update URL given a [=string=] |input| and an
+    [=origin=] |igOwner|:
+
+  1. Let |parsedUrl| be the result of running the [=URL parser=] on |input|.
+  1. Return failure if any of the following conditions hold:
+      * |parsedUrl| is failure;
+      * |parsedUrl|'s [=url/origin=] is not [=same origin=] with |igOwner|;
+      * |parsedUrl| [=includes credentials=];
+      * |parsedUrl|'s [=url/fragment=] is not null.
+  1. [=Assert=]: |parsedUrl|'s [=url/scheme=] is "`https`".
+  1. Return |parsedUrl|.
+

+
+

+  To parse and verify a trusted signals URL given a [=string=] |input|:
+
+  1. Let |parsedUrl| be the result of running the [=URL parser=] on |input|.
+  1. Return failure if any of the following conditions hold:
+      * |parsedUrl| is failure;
+      * |parsedUrl|'s [=url/scheme=] is not "`https`";
+      * |parsedUrl| [=includes credentials=];
+      * |parsedUrl|'s [=url/fragment=] is not null;
+      * |parsedUrl|'s [=url/query=] is not null.
+  1. Return |parsedUrl|.
+

+
 

   To round a value given a {{double}} |value|:
 
@@ -4912,6 +5049,7 @@ dictionary BiddingBrowserSignals {
   sequence prevWinsMs;
   object wasmHelper;
   unsigned long dataVersion;
+  unsigned long crossOriginDataVersion;
   boolean forDebuggingOnlyInCooldownOrLockout = false;
 };
 
@@ -4924,6 +5062,7 @@ dictionary ScoringBrowserSignals {
 
   record renderSize;
   unsigned long dataVersion;
+  unsigned long crossOriginDataVersion;
   sequence adComponents;
   boolean forDebuggingOnlyInCooldownOrLockout = false;
 };
@@ -5150,10 +5289,6 @@ An interest group is a [=struct=] with the following [=struct/items=]
   : trusted bidding signals url
   :: Null or a [=URL=]. Provide a mechanism for making real-time data available for use at bidding
     time. See [=building trusted bidding signals url=].
-    

-      When non-null, the [=interest group/trusted bidding signals url=]'s [=origin=] will always be
-      [=same origin=] with [=interest group/owner=].
-    

   : trusted bidding signals keys
   :: Null or a [=list=] of [=strings=]. See [=building trusted bidding signals url=].
   : trusted bidding signals slot size mode
@@ -5296,10 +5431,6 @@ An auction config is a [=struct=] with the following [=struct/items=]
     Provide a mechanism for making real-time data (information about a specific [=ad creative=])
     available for use at [=evaluate a scoring script|scoring=] time, e.g. the results of some ad
     scanning system.
-    

-      When non-null, the [=auction config/trusted scoring signals url=]'s [=origin=] will always be
-      [=same origin=] with [=auction config/seller=].
-    

   : max trusted scoring signals url length
   :: A {{long}} integer, initially 0. Indicates the maximum trusted scoring signals fetch url length
     for the auction config. 0 means no limit.
@@ -5599,9 +5730,9 @@ To append to a bidding signals per-interest group data map given an [
 
 

 To fetch the current outstanding trusted signals batch given a
-[=trusted bidding signals batcher=] |trustedBiddingSignalsBatcher|, a [=URL=] |signalsUrl|, an
-{{unsigned short}}-or-null |experimentGroupId|, an [=origin=] |topLevelOrigin|,
-and a [=string=] |slotSizeQueryParam|:
+[=trusted bidding signals batcher=] |trustedBiddingSignalsBatcher|, a [=URL=] |signalsUrl|,
+an [=origin=] |scriptOrigin|, an {{unsigned short}}-or-null |experimentGroupId|,
+an [=origin=] |topLevelOrigin|, and a [=string=] |slotSizeQueryParam|:
 
   1. If |signalsUrl| is null, return.
   1. Let |biddingSignalsUrl| be the result of [=building trusted bidding signals url=] with
@@ -5609,7 +5740,7 @@ and a [=string=] |slotSizeQueryParam|:
      |trustedBiddingSignalsBatcher|'s [=trusted bidding signals batcher/ig names=],
      |experimentGroupId|, |topLevelOrigin|, and |slotSizeQueryParam|.
   1. Let « |partialTrustedBiddingSignals|, |partialPerInterestGroupData|, |dataVersion| » be the
-     result of [=fetching trusted signals=] with |biddingSignalsUrl| and true.
+     result of [=fetching trusted signals=] with |biddingSignalsUrl|, |scriptOrigin|, and true.
   1. If |partialTrustedBiddingSignals| is not null:
     1. [=map/For each=] |key| → |value| in |partialTrustedBiddingSignals|, [=map/set=]
       |trustedBiddingSignalsBatcher|'s [=trusted bidding signals batcher/all trusted bidding
@@ -5630,9 +5761,9 @@ and a [=string=] |slotSizeQueryParam|:
 
 

 To batch or fetch trusted bidding signals given a [=trusted bidding signals batcher=]
-|trustedBiddingSignalsBatcher|, [=interest group=] |ig|, a [=URL=] |signalsUrl|, an
-{{unsigned short}}-or-null |experimentGroupId|, an [=origin=] |topLevelOrigin|,
-and a [=string=] |slotSizeQueryParam|:
+|trustedBiddingSignalsBatcher|, [=interest group=] |ig|, a [=URL=] |signalsUrl|,
+an [=origin=] |scriptOrigin| an {{unsigned short}}-or-null |experimentGroupId|,
+an [=origin=] |topLevelOrigin|, and a [=string=] |slotSizeQueryParam|:
 
   1. If |signalsUrl| is null:
     1. [=map/Set=] |trustedBiddingSignalsBatcher|'s [=trusted bidding signals batcher/no signals flags=]
@@ -5671,7 +5802,7 @@ and a [=string=] |slotSizeQueryParam|:
         |putativeLengthLimit|.
   1. Otherwise:
     1. [=Fetch the current outstanding trusted signals batch=] given |trustedBiddingSignalsBatcher|,
-      |signalsUrl|, |experimentGroupId|, |topLevelOrigin|, |slotSizeQueryParam|.
+      |signalsUrl|, |scriptOrigin|, |experimentGroupId|, |topLevelOrigin|, |slotSizeQueryParam|.
     1. If |ig|'s [=interest group/trusted bidding signals keys=] is not null, set
       |trustedBiddingSignalsBatcher|'s [=trusted bidding signals batcher/keys=] to a
       [=list/clone=] of |ig|'s [=interest group/trusted bidding signals keys=].

From 971951cda9c025332bbee60f7f945aedb4743b6b Mon Sep 17 00:00:00 2001
From: Maks Orlovich 
Date: Thu, 11 Jul 2024 11:09:08 -0400
Subject: [PATCH 12/13] Fix wrong indentation level, now I can see in a preview
 diff.

---
 spec.bs | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/spec.bs b/spec.bs
index bd0e1eb9c..13a1603d9 100644
--- a/spec.bs
+++ b/spec.bs
@@ -5689,9 +5689,9 @@ To fetch script given a [=URL=] |url| and a [=script fetcher=] |fetch
     a [=response=] |response|:
     1. If the result of [=validating fetching response headers=] given |response| is false:
       1. [=fetch controller/Abort=] |fetchController|.
-        1. Set |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=] to
-          an empty [=list=] of [=origins=].
-        1. Set |fetcher|'s [=script fetcher/script body=] to failure.
+      1. Set |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=] to
+        an empty [=list=] of [=origins=].
+      1. Set |fetcher|'s [=script fetcher/script body=] to failure.
     1. Set |fetcher|'s [=script fetcher/origins authorized for cross origin trusted signals=] to the
       result of [=parsing allowed trusted scoring signals origins=] given |response|'s [=response/
       header list=].

From 68a730873a2808103dc274665540d1a2640a1ccb Mon Sep 17 00:00:00 2001
From: Maks Orlovich 
Date: Fri, 12 Jul 2024 12:10:49 -0400
Subject: [PATCH 13/13] Fix missing comma.

---
 spec.bs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec.bs b/spec.bs
index 13a1603d9..38824fe1e 100644
--- a/spec.bs
+++ b/spec.bs
@@ -5610,7 +5610,7 @@ headers. It's a [=struct=] with the following [=struct/items=]:
 
 

   : script body
-  :: A [=byte sequence=], null or failure. Initially null. The body of the script.
+  :: A [=byte sequence=], null, or failure. Initially null. The body of the script.
   : origins authorized for cross origin trusted signals
   :: A [=list=] of [=origins=] or null. Initially null. Parsed value of
      [:Ad-Auction-Allow-Trusted-Scoring-Signals-From:].