Review request for Fenced Frames

[shivanigithub]

Braw mornin' TAG!

I'm requesting a TAG review of Fenced Frames.

In a web that has its cookies and storage partitioned by top-frame site, there are occasions (such as Interest group based advertising or Conversion Lift Measurements) when it would be useful to display content from different partitions in the same page. This can only be allowed if the documents that contain data from different partitions are isolated from each other such that they're visually composed on the page, but unable to communicate with each other. Iframes cannot be used for this purpose since they have several communication channels with their embedding frame (e.g., postMessage, URLs, size attribute, etc.). We propose fenced frames, a new element to embed documents on a page, that explicitly aims to prevent communication between the embedder and the frame.

• Explainer: https://github.com/WICG/fenced-frame/tree/master/explainer
• Security and Privacy self-review: see below
• GitHub repo: https://github.com/WICG/fenced-frame/
• Primary contacts:
  • Shivani Sharma (@shivanigithub), Google
  • Dominic Farolino (@domfarolino), Google
  • Josh Karlin (@jkarlin), Google
• Organization/project driving the design: Google, Privacy Sandbox
• External status/issue trackers for this feature: Chrome Status

Further details:

• [✓ ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done: WICG
• The group where standardization of this work is intended to be done: WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • Issue trackers: https://github.com/WICG/fenced-frame/issues
• Major unresolved issues with or opposition to this design:
  • There are some ongoing technical constraints which are being brainstormed as described in Privacy Considerations but no known opposition.
• This work is being funded by: Google

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Security/Privacy Questionnaire

This section contains answers to the W3C TAG Security and Privacy Questionnaire. This section is also documented here.

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

   Fenced frames can be viewed as a more private and restricted iframe. As such, the element does not inherently expose any new information to web sites or third parties. However, fenced frames are intended to contain data that belongs to a partition other than the top-frame’s storage partition e.g. the rendering url in TURTLEDOVE reflects the interest group of the user which may be derived from user activity in another partition. Therefore it is necessary for the fenced frame to attempt to block communications between the fenced frame and its embedder. Fenced frames remove explicit web-platform communication channels between the two (such as postMessage) and many side channels e.g. size, programmatic focus, policy delegation etc. but some side channels still exist and we will continue to work to mitigate them.

2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

   Yes, see above answer for ways information exposure is minimized.

3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

   Fenced frames do not inherently provide personal information, PII or information derived from them.

4. How do the features in your specification deal with sensitive information?

   Same answer as # 3.

5. Do the features in your specification introduce a new state for an origin that persists across browsing sessions?

   No.

6. Do the features in your specification expose information about the underlying platform to origins?

   No

7. Does this specification allow an origin to send data to the underlying platform?

   No

8. Do features in this specification allow an origin access to sensors on a user’s device

   No

9. What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

   Same answer as # 1.

10. Do features in this specification enable new script execution/loading mechanisms?

    No

11. Do features in this specification allow an origin to access other devices?

    No

12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

    No

13. What temporary identifiers do the features in this specification create or expose to the web?

    None.

14. How does this specification distinguish between behavior in first-party and third-party contexts?

    Fenced frames are always present as embedded frames. In terms of communication restrictions from the embedding page, they behave almost like a separate tab but fenced frames do not get access to first-party storage/cookies. A fenced frame document gets access to a nonce-based ephemeral cookie and storage partition.

15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

    No difference with a regular mode browser

16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

    Yes.

17. Do features in your specification enable origins to downgrade default security protections?

    No

18. What should this questionnaire have asked?

    N/A

[lknik]

This seems to be as as major feature guaranteeing this “privacy sandbox” stack to be tight from a privacy point of view. It’s a necessary building block. However, it is tricky to guarantee such tightness.

Were some out of bands leaks covered? For example sensors-based? Can it access accelerometer/camera/etc stuff?

[domfarolino]

It is the intention that permissions requests via the permissions API, permissions policy, etc are all denied in fenced frames. This means that all sensors should be disabled, as per https://w3c.github.io/sensors/#permissions-policy and https://w3c.github.io/sensors/#permissions.

Some of this is documented in https://github.com/WICG/fenced-frame/blob/master/explainer/permission_document_policies.md, but I am not sure if we have sufficiently documented Permissions API yet (@shivanigithub may know).

[shivanigithub]

As @domfarolino mentioned, the sensors will all be disabled inside a fenced frame tree. Other APIs that could be side channels like Navigator.vibrate are also disabled inside a fenced frame tree (code source link). Similarly programmatic focus is disabled as described here. The document also describes other APIs that are on our radar e.g intersection observer.

Updated the documentation here for describing interaction with Permissions API.

[shivanigithub]

As @domfarolino mentioned, the sensors will all be disabled inside a fenced frame tree. Other APIs that could be side channels like Navigator.vibrate are also disabled inside a fenced frame tree (code source link). Similarly programmatic focus is disabled as described here. The document also describes other APIs that are on our radar e.g intersection observer.

Updated the documentation here for describing interaction with Permissions API.

Additionally, would like to point out that many of the side channels have been identified and are documented in the explainer but that may not be an exhaustive list and we look forward to continue adding to it and welcome feedback.

[rhiaro]

From our initial review we think this looks great from a privacy perspective.

Regarding the use cases that Fenced Frames are meeting - how are they currently achieved? What will motivate developers to move to Fenced Frames instead?

We see you expect to move this work to WHATWG - are there positive signals from other implementers in the WHATWG community? Because right now that is not reflected in Chromestatus.

[shivanigithub]

Thanks for the feedback and questions!

From our initial review we think this looks great from a privacy perspective.

Regarding the use cases that Fenced Frames are meeting - how are they currently achieved? What will motivate developers to move to Fenced Frames instead?

The use cases that are motivating fenced frames require some kind of cross-site data access. Currently that is available in iframes as third-party cookies. But once 3p cookies are blocked and iframes only access data partitioned by top-level site, cross-site data can only be allowed if the documents that contain data from different partitions are isolated from each other. Iframes do not suit this purpose since they have several communication channels with their embedding frame (e.g., postMessage, URLs, size attribute, etc.). Fenced frames provide such a construct where the fenced frame document and the embedding document are visually composed on the page, but unable to communicate with each other.

As a specific example, one of the first use cases that fenced frames will solve is interest based advertising. More details of the use case's privacy guarantees are here . One of the guarantees mentioned there is "Web sites the person visits, and the ad networks those sites use, cannot learn about their visitors' ad interests." and this will be achieved by rendering the auction winning ad in a fenced frame as described here.

We see you expect to move this work to WHATWG - are there positive signals from other implementers in the WHATWG community? Because right now that is not reflected in Chromestatus.

We plan to reach out to WHATWG more formally in the coming weeks and get signals. /cc @domfarolino
We have had some initial conversations with other browsers and there has been positive signal from Microsoft Edge (comment)

[plinss]

Just to confirm, I presume that the document embedded in the fenced frame can't tell that it's in a fenced frame? (e.g. doesn't have any access to the fencedframe element, etc.)

Are there any other use cases foreseen for fenced frames besides ads?

Additionally, a few years back when reviewing portals, we had asked to see some work explaining the primitives and models that the various frame types of elements are built on, and how they fit together. I don't recall seeing any output from that and here we have yet another type of frame... I, for one, would still like to see some kind of 'unified frame model'.

[domenic]

I don't recall seeing any output from that and here we have yet another type of frame...

That work is in progress in whatwg/html#6315, in particular the model is described in https://whatpr.org/html/6315/document-sequences.html . Portals/fenced frames/prerendering all would make use of the "non-top level traversable navigable" concept.

[shivanigithub]

Just to confirm, I presume that the document embedded in the fenced frame can't tell that it's in a fenced frame? (e.g. doesn't have any access to the fencedframe element, etc.)

the fenced frame document can actually know if it's a fenced frame because of the availability of certain API namepsaces which are only non-null in a fenced frame document, e.g. window.fence

Are there any other use cases foreseen for fenced frames besides ads?

Yes, non-ads use cases are very much possible with fenced frames. For example, the read-only mode describes the usage for 3rd party payment service provider(PSP)'s customized payment buttons.

[lknik]

As @domfarolino mentioned, the sensors will all be disabled inside a fenced frame tree. Other APIs that could be side channels like Navigator.vibrate are also disabled inside a fenced frame tree (code source link). Similarly programmatic focus is disabled as described here. The document also describes other APIs that are on our radar e.g intersection observer.
Updated the documentation here for describing interaction with Permissions API.

Additionally, would like to point out that many of the side channels have been identified and are documented in the explainer but that may not be an exhaustive list and we look forward to continue adding to it and welcome feedback.

Thanks @shivanigithub @domfarolino, so I reckon that this:

Delegated permissions: Permission delegation restricts permission requests to the top-level frame. Since fenced frames are embedded contexts, they should not have access to permissions, even if they are treated as top-level browsing contexts. Also delegation of permissions from the embedding context to the fenced frames should not be allowed as that could be a communication channel. This is detailed further here.

Would suppose to make it clear, and this is fair. Perhaps it would enhance the clarity if it was expanded a bit? Though I assume that this will be the case in the actual specification document (which would be fine...)

[lknik]

Also of note.

Do you plan to disable some input events that may aid in fingerprinting? That would be a matter of getting rid of access to a clock.

If the plan is to make the thing tight and leak-resistant, perhaps going as far as possible would be a sensible approach.

[shivanigithub]

Delegated permissions: Permission delegation restricts permission requests to the top-level frame. Since fenced frames are embedded contexts, they should not have access to permissions, even if they are treated as top-level browsing contexts. Also delegation of permissions from the embedding context to the fenced frames should not be allowed as that could be a communication channel. This is detailed further here.

Would suppose to make it clear, and this is fair. Perhaps it would enhance the clarity if it was expanded a bit? Though I assume that this will be the case in the actual specification document (which would be fine...)

Right, this would be part of the spec. Also the explainer goes into more details about permissions here.
I will point out though that we are in the process of updating that explainer because of issues like this one where features like attribution reporting will need to be allowed in specific fenced frame modes if it's not disallowed by the top-level page. The guiding principle will stay the same: fenced frames should not be used as a work-around to the top-level page's permission restrictions and permission delegation should not act as a communication channel.

[shivanigithub]

Also of note.

Do you plan to disable some input events that may aid in fingerprinting? That would be a matter of getting rid of access to a clock.

If the plan is to make the thing tight and leak-resistant, perhaps going as far as possible would be a sensible approach.

Agree that there is the issue of network timing side channel (described in the explainer here) and we are considering what a long-term solution for this would look like in fenced frames. The solution will likely also be different for the different modes of fenced frames (e.g. read-only mode completely blocks off network access when it gets read-only cookies access). For the opaque-ads mode, 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.

Re Removing the clock : This was considered, but this is an approach that would require needing to block many APIs and as a result can lead to a lot of content not working inside fenced frames. Additionally as long as the FF has network, the timing can be retrieved from the server at any point.

[igrigorik]

Are there any other use cases foreseen for fenced frames besides ads?

Yes, non-ads use cases are very much possible with fenced frames. For example, the read-only mode describes the usage for 3rd party payment service provider(PSP)'s customized payment buttons.

As signal boost. Want to note strong interest and support for this on behalf of Shopify. Same/similar use case and reasons as outlined here.

[shivanigithub]

As signal boost. Want to note strong interest and support for this on behalf of Shopify. Same/similar use case and reasons as outlined here.

Thanks @igrigorik ! Looking forward to continued discussion with Shopify in the discussion here especially around some of the open questions.

[torgo]

Hi folks - just just reviewing this again today and it still looks like there isn't any multi-browser support… If there are any signals of support from other engines can you let us know and maybe update ChromeStatus as well?

[shivanigithub]

@torgo Thanks for the question on multi-browser support!

We are planning on getting signals from other engines but are currently brainstorming on some API surface questions and plan to reach out to other browsers once those are resolved at our end, for example some of the discussions around WICG/fenced-frame#30 and WICG/fenced-frame#48
Also as mentioned earlier in this issue, there is support from Edge as pointed out in this comment.

[rhiaro]

Thanks again for requesting a review. We're happy with the goals of this work, and think it will be a positive addition to the web platform in the absence of third-party cookies.

We have general concerns about negative impacts if/when it is implemented before third-party cookies are completely phased out. We also remain concerned about how the threat model is changed (eg. introducing new side-channels) when it is used in combination with other work that is emerging to meet use cases which previously needed third-party cookies, in particular the other work coming out of the Privacy Sandbox initiative. We look forward to your ongoing work on ensuring Fenced Frames is sufficiently secure and privacy preserving in the context of the wider ecosystem, and will appreciate another review request when the work has progressed further and with input from other stakeholders.

[shivanigithub]

Thanks so much for the review!

We have general concerns about negative impacts if/when it is implemented before third-party cookies are completely phased out.

Could you elaborate a bit on the concerns with fenced frames before 3p cookies are phased out? Before 3p cookies are removed, we mostly envision them to be used by developers for experimenting the use cases that rely on fenced frames like FLEDGE, Shared Storage etc.

We also remain concerned about how the threat model is changed (eg. introducing new side-channels) when it is used in combination with other work that is emerging to meet use cases which previously needed third-party cookies, in particular the other work coming out of the Privacy Sandbox initiative. We look forward to your ongoing work on ensuring Fenced Frames is sufficiently secure and privacy preserving in the context of the wider ecosystem, and will appreciate another review request when the work has progressed further and with input from other stakeholders.

Sure, we would send another review request once some of the ongoing technical considerations like network side channel, intersection observer etc. have progressed further and we have received more inputs from stakeholders.

[lknik]

For what’s worth, I’d also be interested to learn about the risks of fenced frames prior to the removal ot third-party cookies. One risk I can imagine is the false sense of isolastion — that the developer/user may think that something is tight, but it maybe isn’t. Is that the raised problem here?

[shivanigithub]

For what’s worth, I’d also be interested to learn about the risks of fenced frames prior to the removal ot third-party cookies. One risk I can imagine is the false sense of isolastion — that the developer/user may think that something is tight, but it maybe isn’t. Is that the raised problem here?

@lknik agree that there are existing leaks in FFs, some of them mentioned in the explainer here. To the user, FFs currently do not show any UX difference and since they are strictly better than iframes with 3pc, I think that would be ok. To developers, we could likely clarify the existing documentation enumerating the existing leaks. Would that help?