Merge branch 'main' (the up-to-date one this time) into fledge-currency

WICG · Oct 27, 2023 · b3981f3 · b3981f3
2 parents bd9df9b + dd1e801
commit b3981f3
Show file tree

Hide file tree

Showing 18 changed files with 3,847 additions and 455 deletions.
diff --git a/FLEDGE.md b/FLEDGE.md
diff --git a/FLEDGE_browser_bidding_and_auction_API.md b/FLEDGE_browser_bidding_and_auction_API.md
diff --git a/FLEDGE_k_anonymity_differential_privacy.md b/FLEDGE_k_anonymity_differential_privacy.md
@@ -91,20 +91,20 @@ a set.
 | Parameter          | Value     |
 |--------------------|-----------|
 |Update period $p$   | $p=1$ hour. The k-anonymity server will re-evaluate the _k_-anonymity status of each set once every hour. |
-|Lookback window $w$ | $w=7$ days (168 units of $p$). Join events from the past 7 days will count towards measuring the current set size. |
+|Lookback window $w$ | $w=30$ days (720 units of $p$). Join events from the past 30 days will count towards measuring the current set size. |
 |Set size $k$        | $k=50$. A set must contain at least 50 users (in a noisy sense) to earn positive k-anonymity status. |
 
 
 The differential privacy algorithm needs the $\varepsilon$ (epsilon) and
 $\delta$ (delta) parameters to control the amount of noise added to the true
 set size and the set size threshold. We choose the lowest round value of
-$\varepsilon$ that permits $\delta < 10^{-5}$ given the choice of parameters
+$\varepsilon$ that permits $\delta \sim 10^{-5}$ given the choice of parameters
 $p$, $w$, and $k$ above.
 
 
 | Parameter            | Value     |
 |----------------------|-----------|
-|$\varepsilon, \delta$ | $\varepsilon=3$,  $\delta<10^{-5}$ |
+|$\varepsilon, \delta$ | $\varepsilon=3$,  $\delta\sim 10^{-5}$ |
 
 
 We verified that these parameters resulted in a limited amount of noise (as

diff --git a/FLEDGE_k_anonymity_server.md b/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

diff --git a/Fenced_Frames_Ads_Reporting.md b/Fenced_Frames_Ads_Reporting.md
@@ -45,14 +45,15 @@ The following summarizes the sequence of events for the buyer and seller. Distin
 The following new APIs will be added for achieving this.
 
 
-## reportEvent
+## reportEvent (preregistered destination URL)
 
-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.
+There are two variants of the `reportEvent` API for event-level reporting that are invoked with different sets of parameters. In the first variant, 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.
 
-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.
+This API is available from all documents in a fenced frame that are same-origin to the mapped URL of the fenced frame config (i.e., the ad creative URL that won the Protected Audience auction).
 
 The browser processes the beacon by sending an HTTP POST request, like the existing [navigator.sendBeacon](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon).
 
+Note `window.fence` here is a new namespace for APIs that are only available from within a fenced frame. In the interim period when FLEDGE supports rendering the winning ad in an iframe, `window.fence` will also be available in such an iframe.
 
 ### Parameters
 
@@ -104,8 +105,25 @@ window.fence.reportEvent({
 });
 ```
 
+## reportEvent (custom destination URL with substitution of preregistered macros)
 
-Note `window.fence` here is a new namespace for APIs that are only available from within a fenced frame. In the interim period when FLEDGE supports rendering the winning ad in an iframe, `window.fence` will also be available in such an iframe.
+In the second `reportEvent` variant, fenced frames can invoke the `reportEvent` API to tell the browser to send a beacon to a specified destination URL, where macros in the URL are substituted to values registered by the buyer's worklet in `registerAdMacro` (see below). This specified URL must be a valid HTTPS URL.
+
+This API is available in the same contexts as `reportEvent` to a preregistered destination, i.e., documents that are same-origin to the fenced frame config's mapped URL. However, there are additional restrictions on the origin of the destination URL. The interest group declaration includes an allowlist of origins that may receive reports using this mode of `reportEvent` (custom destination URL with macro substitution). If at any point a report is attempted to a disallowed origin, access to this mode of `reportEvent` will be shut off for any ad loaded from this fenced frame config, for privacy reasons (to prevent reidentification by using the allowlist to encode cross-site data about a user in binary with its choices of allowed/disallowed origins). Note that this only applies to this mode of `reportEvent`: `reportEvent` to a preregistered destination will still work.
+
+Unlike `reportEvent` to a preregistered destination, here the browser processes the beacon by sending an HTTP GET request, as per feedback here: https://github.com/WICG/turtledove/issues/477#issuecomment-1524158476.
+
+### Parameters
+
+**Destination URL:** Includes the desired destination URL for the report, with macros to be substituted based on the buyer worklet's specified values.
+
+### Example
+
+Here is an example that will substitute `${PUBLISHER_ID}` and `${SOURCE_URL_ENC}` macros based on values specified in the buyer worklet.
+```
+window.fence.reportEvent({
+  'destinationURL': 'https://adtech.example/impression?cid=555&pub_id=${PUBLISHER_ID}&site=${SOURCE_URL_ENC}&t=123'});
+```
 
 ## registerAdBeacon
 
@@ -127,6 +145,21 @@ registerAdBeacon({
 });
 ```
 
+## registerAdMacro
+Bidder worklets are able to register macros with the browser in their `reportWin()` function. The registered macro values are used to substitute macros in the destination URL of the `reportEvent()` API's parameter.
+
+### Parameters
+Two strings.
+**macro name** It’s case sensitive, e.g., `“PUBLISHER_ID”`. 
+
+**macro value** The value of the macro that is used to substitute the macro (e.g., ${PUBLISHER_ID}) in `reportEvent()` API’s destination URL parameter.
+
+### Example
+```
+registerAdMacro(‘PUBLISHER_ID’, ‘123a’);
+registerAdMacro(‘SOURCE_URL_ENC’, ‘http%3A%2F%2Fpub%2Eexample%2Fpage’);
+```
+
 ## Support for Attribution Reporting 
 ### Goals
 *   While fenced frames still have unrestricted network access and FLEDGE supports event-level reporting, the solution below takes advantage of the `registerAdBeacon`/`reportEvent` information flow to enable [registering attribution sources](https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources). [ARA attribution triggering](https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#triggering-attribution) is unchanged for registered FLEDGE impressions.
@@ -164,7 +197,7 @@ Since the `reserved.top_navigation` beacons are automatically generated by the b
 window.fence.setReportEventDataForAutomaticBeacons({
   'eventType': 'reserved.top_navigation',
   'eventData': 'an example string',
-  'destination':['seller', 'buyer']
+  'destination': ['seller', 'buyer'],
 });
 ```
 
@@ -177,6 +210,14 @@ If invoked multiple times, the latest invocation before the top-level navigation
 
 If `setReportEventDataForAutomaticBeacons` is not invoked, the browser will not send an automatic beacon because the `destination` is unknown.
 
+An automatic beacon can be manually cleared out by calling `setReportEventDataForAutomaticBeacons` with an empty destination list.
+```
+window.fence.setReportEventDataForAutomaticBeacons({
+  'eventType': 'reserved.top_navigation',
+  'destination': [],
+});
+```
+
 `setReportEventDataForAutomaticBeacons` can also be invoked in the click handler of an anchor tag, and will be sent on navigation:
 
 ```
@@ -196,7 +237,23 @@ function addBeaconData(element) {
 
 The beacon data will be in place by the time that the navigation starts. When the navigation commits, the automatic beacon will be sent out with event data set to "link1 was clicked.".
 
+The dictionary passed into `setReportEventDataForAutomaticBeacons` also takes an optional `once` boolean that defaults to false. If `once` is set to true, the automatic beacon will only be sent for the next `reserved.top_navigation` event. Beacons will not be sent for subsequent `reserved.top_navigation` events until `setReportEventDataForAutomaticBeacons` is invoked again. When used with a click handler, this can be used to send beacons only for specific top-level navigations, rather than for every top-level navigation.
+
+For example, if a frame has multiple links that can perform top-level navigations, but only one of the links should have an automatic beacon associated with it, `setReportEventDataForAutomaticBeacons()` can be called in that link's click handler with `once` set to true. This will ensure that, if another link is clicked after the link with the associated automatic beacon, that other link will not result in a beacon being sent out.
+
+```
+window.fence.setReportEventDataForAutomaticBeacons({
+  'eventType': 'reserved.top_navigation',
+  'eventData': 'an example string',
+  'destination': ['seller', 'buyer'],
+  'once': true,
+});
+```
+
 # 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.
 

diff --git a/fledge-tester-list.md b/fledge-tester-list.md
@@ -42,33 +42,39 @@ The usefulness of this page depends on testers sharing information and updates.
 
 | Company / Party | Role in testing | Est. Testing Timeframe | Link to testing plan and/or learnings | How to contact you |
 | --------------- | --------------- | ---------------------- | ------------------------------------- | ------------------ |
-| Criteo | DSP | | | [email protected] |
-| Teads | SSP & DSP | | | [email protected] |
+| Criteo | DSP | Started in 2022, long term commitment | [An update on FLEDGE testing](https://medium.com/criteo-engineering/an-update-on-fledge-chrome-testing-d0046430a3ec)| [email protected] |
+| Criteo | SSP | November 2023 | | [email protected] |
+| Teads | DSP | January 2024 | | [email protected] |
+| Teads | SSP | January 2024 | | [email protected] |
 | NextRoll | DSP | 2024-01-30 | coming soon | [email protected] |
 | OpenX | SSP | Limited testing in progress | | [email protected] |
 | RTB House | DSP | Continuous testing ongoing; long term commitment. | https://blog.rtbhouse.com/whitepaper-deep-insights-from-early-fledge-experiments/ | [email protected] |
-| SMN | DSP | | | [email protected] |
+| SMN | DSP | no later than January 31, 2024 | | [email protected] |
 | Raptive | Testing as DSP & SSP & Ad management service | ongoing | | [email protected] |
-| CyberAgent(Dynalyst) | DSP | | | [email protected] |
+| CyberAgent(Dynalyst) | DSP | No later than January 31, 2024 | | [email protected] |
 | Google Ad Manager + AdSense (including with Authorized Buyers) | SSP | Testing ongoing | [Publishers (Ad Manager)](https://support.google.com/admanager/answer/12052605?hl=en) <br/> [Publishers (AdSense)](https://support.google.com/adsense/answer/12570693)  <br/> [Authorized Buyers (DSPs)](https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial#onboarding) <br/> [Multi-seller auction support](https://github.com/google/ads-privacy/tree/master/proposals/fledge-multiple-seller-testing) | Publishers with questions should reach out via their account manager directly, or via our [support channels](https://support.google.com/admanager/gethelp).<br/><br/>Authorized Buyers (DSPs) interested in testing should follow the steps listed in the [onboarding guide](https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial#onboarding).<br/><br/>For technical questions on the experimental GPT API for multi-seller auctions, reach out via the “send feedback” button on the [GPT developer site](https://developers.google.com/publisher-tag/reference).| 
 | Google Ads + Display & Video 360 | DSP | Testing in progress | [Help Center Article](https://support.google.com/google-ads/answer/13626996?hl=en&ref_topic=13627218&sjid=16039190573195292133-NA) <br/> [Integration Guide for SSPs](https://developers.google.com/display-video/protected-audience/ssp-guide) <br/>   | Advertisers with questions can reach out via their account manager, or directly via this [form](https://docs.google.com/forms/d/1es8wVNYKD2PStYzE8atqZv4OJr3tuavWNMkmVcWRFQI/viewform?ts=63570235&edit_requested=true).| 
 | MicroAd | SSP & DSP | | | [email protected] |
-| Neodata Group | SSP & DSP | | | privacysandbox@neodatagroup.com |
+| Blendee | SSP & DSP | | | privacysandbox@blendee.com |
 | Adlook (subsidiary of RTB House) | DSP | Continuous testing ongoing; long term commitment. | | [email protected] |
 | Microsoft (Xandr, MSAN) | SSP + DSP(s) | Testing | | [email protected] |
-| Tremor International | SSP & DSP| 2023-2024 | coming soon | [email protected] |
-| Triplelift | SSP | Testing in progress | | [email protected] |
-| Seedtag | SSP & DSP| 2023-2024 | coming soon | [email protected] |
-| Index Exchange | SSP | Testing in progress | | [email protected] |
-| PubMatic | SSP | 2023-2024 | | [email protected] |
-| Adform | DSP & SSP | 2023-2024 | | [email protected] |
+| Nexxen (Unruly/Tremor/Amobee) | SSP & DSP| 2023-2024 | coming soon | [email protected] |
+| Triplelift | SSP | Jan 2024 | | [email protected] |
+| Seedtag | SSP | January 2024 | coming soon | [email protected] |
+| Index Exchange | SSP | By January 31, 2024 | | [email protected] |
+| PubMatic | SSP | Jan 2024 | | [email protected] |
+| Adform | DSP | Beginning January 1, 2024 | | [email protected] |
+| Onetag | DSP & SSP | 2023-2024 | | [email protected] |
+| Yahoo Inc | DSP | beginning 15 Jan 2024 | | [email protected] |
+| Magnite | SSP | January 2024 | | [email protected] |
 
 ## 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.
 
 | Company / Party | Role (publisher/sellside, advertiser/buyside, etc.) | Additional details about your interest (Optional) | How to contact you |
 | --------------- | --------------------------------------------------- | ------------------------------------------------- | ------------------ |
 | Mail Metro Media | Publisher | Transact through Google Ad Manager and Prebid fledgeForGpt module | [email protected] |
+| CNN Brasil | Publisher | | [email protected] |
 | Vocento | Publisher | | [email protected] |
 | Clarin | Publisher | | [email protected] |
 | Terra Networks | Publisher | | [email protected] |