Re: [w3ctag/design-reviews] Specification review for fenced frames (Issue #838)

> Hi @blu25 - we are just reviewing it today. We appreciate you taking the time to collate the information you've provided. However, it's difficult for us to parse the list - which is a lot of links to PRs where you need a lot of context to understand how they fit in, context that we lack. This is one reason we ask for explainers with reviews - which provide that context.
> 
A majority of the changes listed in this list are part of the “Fenced Frames Ads Reporting (FFAR)” infrastructure that is explained in detail in this explainer: https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md which is a short to medium term solution provided for Protected Audience adopters to be able to report on ad impressions within a fenced frame. Since some of the API surfaces are invoked from the fenced frame, they are part of the fenced frames spec but FFAR is ultimately a Protected Audience solution and is not core to fenced frames functionality.


Given your stated objection to Protected Audience, we ask that you instead consider only the following change from the above list that impacts fenced frames in general:  Serializable Fenced Frames Configs.

> I'd also like to point out that we've returned a [negative review on Protected Audience](https://github.com/w3ctag/design-reviews/issues/723#issuecomment-1944367149). So if there is a hard dependency now between this work and Protected Audience then it's unlikely that this will get a positive review from TAG.
> 
> Even so, we strongly recommend that you write an **explainer** which talks through this proposal, starting from **user needs** - as documented in our [explainer guide](https://tag.w3.org/explainers/).

To add to above, fenced frames do not have a dependency on Protected Audience and are a generic element providing stronger isolation between the embedder and the frame, such that they are visually composed on the same page but cannot join cross-site identifiers. As the [TAG had requested above](https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1892661808), the updated use cases document is now published [here](https://github.com/WICG/fenced-frame/blob/master/explainer/use_cases.md). 
As an example of non-Protected Audience use case that fenced frames intend to support, as mentioned in the [earlier comment](https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1667970369), we are in the process of adding functionality for local unpartitioned data access which will support use cases like personalized payment buttons. That functionality is described in this [explainer](https://github.com/WICG/fenced-frame/blob/master/explainer/fenced_frames_with_local_unpartitioned_data_access.md) and the spec is currently in progress. Since this is a major update, we are happy to open a new TAG request specifically for this when the spec is more ready, or add to this request, as the TAG reviewers may see fit.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/838#issuecomment-2153021598
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/838/2153021598@github.com>