renaming FLEDGE to Protected Audience

explainer/use_cases.md

@@ -12,24 +12,24 @@ This document summarizes the various use cases for [fenced frames](https://githu
 
 
 *   All use cases are similar such that they are isolated from the embedded context via any JS window references, script access, storage access, resizing of the fenced frame, messaging APIs etc.
-*   Every use case of fenced frame is different in how its privacy guarantees are preserved and would need a separate launch/review process. The first phase and the associated review process of fenced frames will focus only on its use by FLEDGE, sharedStorage, and the default `FencedFrameConfig()` constructor(s).
+*   Every use case of fenced frame is different in how its privacy guarantees are preserved and would need a separate launch/review process. The first phase and the associated review process of fenced frames will focus only on its use by Protected Audience, sharedStorage, and the default `FencedFrameConfig()` constructor(s).
 *   Each use case’s source url privacy characteristics are different E.g. the “opaque-ads” use case allows providing a config-bound opaque src by the embedder which contains cross-site data e.g. interest groups, the “read-only” use case has src that is known to the embedder and does not need to be mitigated against link decoration. A future “unpartitioned-storage” use case will need the src to be mitigated against link decoration.
 *   One of the questions we are trying to answer from an API perspective is how to represent these different use cases of fenced frames. Should they be separate elements, all inheriting the base Fenced Frame element; or should they be the same element where you can set an attribute to load configs generated by different APIs; or a hybrid between these two approaches? In phase 1, for simplicity, we are going with it as an attribute and then if need be and based on TAG/standards discussions, we can pivot to create separate elements.
 
 
 ## **Opaque-ads**
 
-This use case is for rendering ads whose url is opaque to the embedding context. The two consumers of this use case are [FLEDGE](https://github.com/WICG/turtledove/blob/main/FLEDGE.md) and [SharedStorage](https://github.com/pythagoraskitty/shared-storage#simple-example-consistent-ab-experiments-across-sites). 
+This use case is for rendering ads whose url is opaque to the embedding context. The two consumers of this use case are [Protected Audience](https://github.com/WICG/turtledove/blob/main/FLEDGE.md) and [SharedStorage](https://github.com/pythagoraskitty/shared-storage#simple-example-consistent-ab-experiments-across-sites). 
 
 
 
 *   **Use case: “opaque-ads”**
 *   **Config:**
-     *   Generated by FLEDGE (`navigator.runAdAuction()`) or SharedStorage (`window.sharedStorage.selectURL`).
+     *   Generated by Protected Audience (`navigator.runAdAuction()`) or SharedStorage (`window.sharedStorage.selectURL`).
      *   The url mapped by the config can only be an https, localhost, about:blank.
      *   Note that for this use case, the interesting part is that the source is opaque to the publisher and that is what is discussed in the information flow section below.
 
-*   **Example** usage from FLEDGE:
+*   **Example** usage from Protected Audience:
     ```js
     navigator.runAdAuction(myAuctionConfig).then((auctionWinnerConfig) => {
       // auctionWinnerConfig value e.g.
@@ -52,8 +52,8 @@ This use case is for rendering ads whose url is opaque to the embedding context.
     * The network access being unrestricted is an ongoing technical challenge due to the issue of network timing side channel (described in the explainer [here](https://github.com/WICG/fenced-frame/blob/master/explainer/network_side_channel.md)) and we are considering what a long-term solution for this would look like in fenced frames. For the opaque-ads use case, the considerations are either 1) denying any network access (e.g., loaded via navigable web bundles) or 2) network access only allowed to some trusted caching service that promises to only log aggregate data.    
     *   Like all use cases, the fenced frame is isolated from the embedded context via any JS window references, script access, storage access, messaging APIs etc. The fenced frame does not know the embedding site’s origin or etld+1.
     *   The fenced frame is allowed to create a popup (with noopener) or navigate the top-level page on user activation as described [here](https://github.com/WICG/fenced-frame/blob/master/explainer/integration_with_web_platform.md#top-level-navigation). (This is an ads requirement)
-*   **Cross-site data**: Interest groups in Fledge, the cross-site data used to choose the one-of-N URLs for shared storage. 
-*   **Reporting**: Reporting for ads would eventually be done using aggregate reporting but for easier adoption there is event-level reporting that will be allowed. Events happening inside the fenced frames will be joined with the data from the FLEDGE/SharedStorage worklet and sent as a beacon. This is detailed [here](https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md)   
+*   **Cross-site data**: Interest groups in Protected Audience, the cross-site data used to choose the one-of-N URLs for shared storage. 
+*   **Reporting**: Reporting for ads would eventually be done using aggregate reporting but for easier adoption there is event-level reporting that will be allowed. Events happening inside the fenced frames will be joined with the data from the Protected Audience/SharedStorage worklet and sent as a beacon. This is detailed [here](https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md)   
 
 
 ## **Default**