Shared Storage use cases within Fenced Frame

[xyaoinum]

Currently, Fenced Frames disallow all Permission policies for privacy reasons.

Shared Storage is going to add its permissions policy as well. The following Shared Storage use cases will benefit from being allowed from inside the Fenced Frame:

• A/B Experiments - Shared storage allows for assigning experiment groups to users and selecting between up to 8 different urls to display to a user. The URL selection is done from a javascript worklet, and the selected URL is rendered by a fenced frame. However, to measure the effectiveness of the experiment, the organization needs to be able to send a report to an aggregation service. It is important to send the report from within the fenced frame, and not from within the JS worklet, as orgs will want to confirm the content successfully loaded prior to sending a report, which is particularly important if the content is an ad a brand is paying for. 
• Multiple, nested url selection calls - while likely a future use case, there is a potential need to allow multiple organizations to utilize shared storage to prevent one entity further upstream (say for example in an ad decision chain) from preventing other organizations from utilizing shared storage (we will need to ensure we are “budgeting” properly for entropy leakage, hence why it is a future/under consideration use case). It is likely that if an SSP uses some information from shared storage to then render a URL within a fenced frame pointing to a DSP, that the DSP would be unable to reference information in its own shared storage to further refine the ad decision. 

[shivanigithub]

The proposed solution in this issue comment will also apply here.

[domfarolino]

@blu25 Do you think this can be closed now, given the fact that the permissions policies that are enabled in a fenced frame are entirely up to the config-generating API at this point?

[domfarolino]

Ping @blu25