Intent to prototype: fenced frames with local unpartitioned data access
Shivani Sharma
Contact emails
shiva...@chromium.org, jka...@chromium.org
Explainer
Specification
The fenced frames and shared storage specs will be updated with these changes.
Blink component
Summary and Motivation
There are situations in which it is helpful to decorate a third-party widget with cross-site information about the user, such as a personalized payment button that displays credit card information to give the user confidence that the payment flow will be smooth, 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 composed within a page of another partition. 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, the payment site would 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.
To prevent the fenced frame from leaking the user’s shared storage data out (to the embedder or to servers via network) we’re requiring that fenced frames first disable all untrusted network communications before accessing shared storage.
The 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 intended to be restricted to payments. Any form of third-party UX that wishes to show personalized information to a user, without leaking that information to the embedder, could use it.
Initial public proposal
TAG review
To be requested
Risks
Interoperability and Compatibility
The functionality is purely additive and does not have backward compatibility concerns. There are no interoperability risks as no other browsers have decided to implement these features yet.
Web developers: Positive (comment on the TAG review showing support)
Other signals: We have also heard from TAG reviewers about fenced frames’ capability to support non-ads use cases, as given here and this solution will enable such use cases.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None, fenced frames and shared storage are not currently supported on WebView
Debuggability
No additional capabilities required from dev tools
Is this feature fully tested by web-platform-tests?
No
WPT tests will be written and submitted while working on this feature.
Flag name on chrome://flags
None yet
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1294933
Estimated milestones
M124