Add clearOriginJoinedAdInterestGroups()

FLEDGE_k_anonymity_server.md

@@ -18,15 +18,7 @@ where the crowd consists of $k$ users.
 
 ## Use cases in the Privacy Sandbox
 
-The [FLEDGE](FLEDGE.md) proposal calls for k-anonymity thresholds on several
-features.  The first threshold is before interest groups are updated.
-A browser should not request an interest group update from an untrusted
-server unless there are at least $k$ other browsers also requesting the
-same interest group update.  This allows the browser for a particular user
-to _hide in the crowd_ of other users also requesting the same update.
-To implement this k-anonymity thresholds are applied to the `dailyUpdateUrl`.
-
-k-anonymity is also applied to the `renderUrl` for ad creatives.  One of the
+k-anonymity is applied to the `renderUrl` for ad creatives.  One of the
 goals of [FLEDGE](FLEDGE.md) is to offer microtargeting protection; that is,
 a user won't be shown an ad unless some minimum number, $k$, of other users
 are also being shown the same ad.  This is accomplished by applying k-anonymity
@@ -37,6 +29,26 @@ being passed to an ad's fenced frame via parameters like `size`.  Adding `size`
 to the k-anonymity check of the `renderUrl` is under discussion in [this
 issue](https://github.com/WICG/turtledove/issues/312#issuecomment-1307471709).
 
+k-anonymity is also applied at Reporting Time: if the buyer has provided a `reportWin`
+function in the script available at `biddingScriptUrl`, the `browserSignals` argument
+to the `reportWin` function call will include `interestGroupName` if the tuple of 
+interest group owner, name, bidding script URL and ad creative URL is jointly 
+k-anonymous (see 
+[here](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#52-buyer-reporting-on-render-and-ad-events)).
+
+
+Previously the [FLEDGE](FLEDGE.md) proposal called for k-anonymity thresholds on 
+Interest Group updates. The idea was a browser would not request an Interest Group 
+update from an untrusted server unless there were at least $k$ other browsers also 
+requesting the same Interest Group update. This meant a k-anon check was done on
+the Interest Group's `dailyUpdateUrl`. After much discussion (in particular see
+this comment on the proliferation of Interest Groups causing tradeoffs w/r/t latency
+[here](https://github.com/WICG/turtledove/issues/361#issuecomment-1430069343), and
+the bottom of section 1.2 discussing the `updateUrl` (`dailyUpdateUrl`) in the main explainer
+[here](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#12-interest-group-attributes)) 
+it was decided to drop this requirement as the marginal cost to the auction was large
+and the marginal benefit to privacy not enough.
+
 Beyond FLEDGE there are also plans to use k-anonymity thresholds in [shared
 storage](https://github.com/WICG/shared-storage).  The shared storage
 `selectURL` API may require that the returned URL meets a k-anonymity

Fenced_Frames_Ads_Reporting.md

@@ -47,7 +47,7 @@ The following new APIs will be added for achieving this.
 
 ## reportEvent
 
-Fenced frames can invoke the `reportEvent` API to tell the browser to send a beacon with event data to a URL registered by the worklet in `registerAdBeacon` (see below). Depending on the declared `destination`, the beacon is sent to either the buyer's or the seller's registered URL. Examples of such events are mouse hovers, clicks (which may or may not lead to navigation e.g. video player control element clicks), etc.
+Fenced frames can invoke the `reportEvent` API to tell the browser to send a beacon with event data to a URL registered by the worklet in `registerAdBeacon` (see below). Depending on the declared `destination`(s), the beacon is sent to either the buyer's and/or the seller's registered URL. Examples of such events are mouse hovers, clicks (which may or may not lead to navigation e.g. video player control element clicks), etc.
 
 This API is available from same-origin frames within the initial rendered ad document and across subsequent same-origin navigations, but it's no longer available after cross-origin navigations or in cross-origin subframes. (For this API, for chains of redirects, the requestor is considered same-origin with the target only if it is same-origin with all redirect URLs in the chain.) This way, the ad may redirect itself without losing access to reporting, but other sites can't send spurious reports.
 
@@ -218,6 +218,9 @@ window.fence.setReportEventDataForAutomaticBeacons({
 ```
 
 # Support for Ad Components
+For ad components [rendered in fenced frames](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#4-browsers-render-the-winning-ad), the support for event-level reporting described below is available in Chrome starting M114. 
+For ad components rendered in iframes, the support will be available in Chrome starting M115. The support works for all combinations of the top-level ad and ad component being rendered in iframes and/or Fenced Frames.
+
 ## Goal
 When a rendered ad is composed of [multiple pieces](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#34-ads-composed-of-multiple-pieces), it is useful to detect user clicks that happened on ad components.
 

fledge-tester-list.md

@@ -66,7 +66,7 @@ The usefulness of this page depends on testers sharing information and updates.
 | Adform | DSP | Beginning January 1, 2024 | | privacysandbox@adform.com |
 | Onetag | DSP & SSP | 2023-2024 | | privacysandbox@onetag.com |
 | Yahoo Inc | DSP | beginning 15 Jan 2024 | | googleprivacysandbox@yahooinc.com |
-| Magnite | SSP | January 2024 | | rsachdev@magnite.com |
+| Magnite | SSP | January 2024 | | privacysandbox@magnite.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.