Open shivanigithub opened 4 months ago
hober
commented
3 months ago 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
commented
2 months ago 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, https://github.com/w3ctag/design-reviews/issues/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
commented
2 months ago 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
And this TAG review that specifically focuses on local unpartitioned data access rendering
If it is recommended to instead converge this issue with https://github.com/w3ctag/design-reviews/issues/838 to review all use cases together, we could do that.
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.Further details:
Security and Privacy questionnaire based on https://www.w3.org/TR/security-privacy-questionnaire/
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.
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.
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.
How do the features in your specification deal with sensitive information?
Same answer as # 3.
Do the features in your specification introduce a new state for an origin that persists across browsing sessions?
No.
Do the features in your specification expose information about the underlying platform to origins?
No
Does this specification allow an origin to send data to the underlying platform?
No
Do features in this specification allow an origin access to sensors on a user’s device
No
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.
Do features in this specification enable new script execution/loading mechanisms?
No
Do features in this specification allow an origin to access other devices?
No
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No
What temporary identifiers do the features in this specification create or expose to the web?
None.
How does this specification distinguish between behavior in first-party and third-party contexts?
Fenced frames are always present as embedded frames.
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
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes, privacy considerations and security considerations.
Do features in your specification enable origins to downgrade default security protections?
No
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 expectation that the unpartitioned data read from within a fenced frame should be available when the document is restored.
N/A