Fenced frames with local unpartitioned data access

[shivanigithub]

I'm requesting a TAG review of Fenced Frames with local unpartitioned data access.

Overview of proposal
There are situations in which it is helpful to personalize content on pages with cross-site data, such as knowing whether a user has an account with a third-party service, whether a user is logged in, displaying the last few digits of a user’s credit card to give them confidence that the check-out process will be seamless, or a personalized sign-in button. These sorts of use cases will be broken by third-party cookie deprecation (3PCD). Fenced frames are a natural fit for such use cases, as they allow for frames with cross-site data to be visually composed within a page of another partition but are generally kept isolated from each other.
The idea proposed here is to allow fenced frames to have access to the cross-site data stored for the given origin within shared storage. In other words, a payment site could add the user’s payment data to shared storage when the user visits the payment site, and then read it in third-party fenced frames to decorate their payment button.
Today’s fenced frames prevent direct communication with the embedding page via the web platform, but they have network access, allowing for data joins to occur between colluding servers. Since the fenced frame in this proposal would have unfettered access to user’s cross-site data, we cannot allow it to talk to untrusted networks at all once it has been granted access to cross-site data. Therefore, we require that the fenced frame calls window.fence.disableUntrustedNetwork() before it can read from shared storage.
The driving motivation for this variant of fenced frames are customized payment buttons for third-party payment service providers (as discussed in this issue) but this proposal is not restricted to payments and we anticipate many other content personalisation use cases will be found with time.

• Explainer¹ (minimally containing user needs and example code): [url]
• User research: For the personalized payment button use case: summary of impact by Google Pay, support from the ecosystem
• Security and Privacy self-review²: see below
• GitHub repo: [url]
• Primary contacts (and their relationship to the specification):
  • Shivani Sharma (@shivanigithub), explainer author
• Organization/project driving the design: Google, Privacy Sandbox
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Use Fenced Frame read-only mode for payment buttons WICG/fenced-frame#15

Further details:

• [✓ ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG HTML Standard
• Existing major pieces of multi-implementer review or discussion of this design: None yet
• Major unresolved issues with or opposition to this design: None
• This work is being funded by: Google Privacy Sandbox

Security and Privacy questionnaire based on https://www.w3.org/TR/security-privacy-questionnaire/

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. Fenced frames with the unpartitioned data access allows it to read unpartitioned data from shared storage to show personalized user information to the user, e.g. personalized payment button as described in the explainer. Existing fenced frames functionality already disables communication from the fenced frame to the embedding context but to access the unpartitioned data, the fenced frame is also required to disable network communications, with exceptions such as private aggregation report as described in the explainer here.

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?

   Any unpartitioned data that the fenced frames read, if it contains PII, is not exfiltrated out of the fenced frame.

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.

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, privacy considerations and security considerations.

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

    No

18. How does your feature handle non-"fully active" documents?

Based on https://www.w3.org/TR/design-principles/#support-non-fully-active:

• There is no user interaction with the fenced frame in a non-fully-active document.
• There is no cross-document interaction/resource sharing possible (e.g. holding locks) in a fenced frame.
• There is no expectation that the unpartitioned data read from within a fenced frame should be available when the document is restored.

19. What should this questionnaire have asked?

    N/A

[hober]

Recent discussion on #838 (the overall design review of Fenced Frames) covered the "last 4 digits" payment use case. Would you like us to move discussion of that particular use case to this issue? If so, how would you like us to down-scope issue #838?

[shivanigithub]

Recent discussion on #838 (the overall design review of Fenced Frames) covered the "last 4 digits" payment use case. Would you like us to move discussion of that particular use case to this issue? If so, how would you like us to down-scope issue #838?

Yes I think focusing this issue for "local unpartitioned access" makes sense, since that's an added major functionality on existing fenced frames.
With that, #838 can then be scoped to the fenced frame API and its core design pieces, including but not limited to being treated as a separate browsing context, it's navigation using fencedFrameConfig object etc.
PLMK if there are any more clarifications on this, thanks!

[shivanigithub]

To give some more context on the 3 fenced frames TAG reviews so far:

These 2 that were created where fenced frames support use cases requiring src which should be hidden from the embedder. Examples of these use cases are Protected Audience and selectURL

• "early design" Review request for Fenced Frames #735 which was resolved positively
• "specification review" Specification review for fenced frames #838

And this TAG review that specifically focuses on local unpartitioned data access rendering

If it is recommended to instead converge this issue with #838 to review all use cases together, we could do that.