Fenced frames should allow for the Attribution Reporting API

[csharrison]

Currently, Fenced Frames disallow all Permission policies for privacy reasons:
https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md

This currently breaks the Attribution Reporting API in Fenced Frames which has the permission policy attribution-reporting:
https://wicg.github.io/attribution-reporting-api/#permission-policy-integration

Using Attribution Reporting API in fenced frames is likely essential for some ads use-cases (e.g. using attribution api with FLEDGE). So we should fix this.

Proposal:

We should allow the Attribution Reporting API in "opaque-ads mode" fenced frames by default, and only allow the creating of "opaque-ads mode" Fenced Frames for a particular origin if the Attribution Reporting API is allowed for that origin.

This limits the ability for sites to use "opaque-ads mode" without the Attribution Reporting API, but that seems manageable, given that ads-mode Fenced Frames probably are all interested in the measurement APIs anyway.

See WICG/turtledove#281 for more context.

[domfarolino]

@blu25

[blu25]

We do need to be careful to ensure there's no risk of leaking information across the fenced boundary. There are a couple ways to do this:

1: Allow creating an opaque-ads fenced frame only if attribution reporting API is allowed for every origin, and then override the fenced frame's policy to allow all.
2: Allow navigating an opaque-ads fenced frame if attribution reporting API is allowed for the fenced frame's origin, and then override the fenced frame's policy to allow all.

We discussed offline and agreed that the 2nd solution is the better one, since the attribution reporting policy is delegated to child frames where they can change the policy as they please, so option 1 would be adding unnecessary restrictions.

Once in the fenced frame, allow attribution reporting for all origins (overriding the default of only allowing it for same-origin subframes) unless explicitly disabled by the page's headers. It will ignore the headers of its embedder to stop the communication channel.

[shivanigithub]

The proposal below allows fenced frames to be delegated permissions similar to iframes but with some additional privacy gates like k-anonymity being applied to the permissions in addition to the url.

Summary
The proposed approach extends fenced frames to have the "allow" attribute similar to iframes as well as allows APIs like FLEDGE and SharedStorage to be able to associate a fenced frame with a set of permissions that are ok to be enabled in the FF document if the embedder also delegates it. The APIs will ensure that this set of permissions is verified for k-anonymity along with the url.

Details
The document here goes into more details of this solution and will be integrated in the explainer after an initial review.

[csharrison]

Thanks @shivanigithub , that proposal seems fine with me!

[shivanigithub]

The document linked in the comment above is posted in the explainer here
The changes in the document require FLEDGE API changes for IGs to declare if they are ok with a FF to load without ARA and have that be part of the k-anonymity check.
In the short term ARA support is now by default on in all FLEDGE FFs unless disallowed by the top-level page, thus closing this issue.

[cklim483]

#56