#975: Fenced frames with local unpartitioned data access
Discussions
2024-10-28
Looking to close with unsatisfied. Martin will draft something that will likely be very spicy. Jeffrey will help make that less overtly offensive.
2024-11-04
Jeffrey: close to closing, comments from me and Martin
Tess: wasn't super enthused about the start of your comment. What is the use case we agree with? Having pay buttons on the web at all?
Jeffrey: the idea that having a pay button that you click on then there's no information to help you with paying is a bad experience
Tess: right now you get to a checkout page and there's paypal and apple pay and google pay etc and you click on one of the buttons. And it works or doesn't. The use case they're trying to solve specifically is I don't remember offhand as a user if I provisioned a card yet in apple pay and the button on the page doesn't suggest to me whether I have or not so I don't know if clicking on that button will be faster or slower than filling out the form myself
Jeffrey: you click apple pay, it didn't work, you click paypal, that's another part. It didn't tell you you should use paypal not apple pay
Tess: it couldn't have known that beforehand. I'm wary of describing the use case of anything vaguer than trying to make that button look like you've already configured google pay so you can trust that you can be faster to click on it than not. That's the actual use case. We already have payment request. It has to be more specific than an api that already exists.
Jeffrey: Right. That was meant as context for the rest. Shortening that makes sense. My goal is to identiy a reasonable use case.
Tess: i suspect I could get behind some description of the use case
Matthew: I've read both comments, Jeffrey's is more dispassionate. It can't be misinterpreted as us saying they're bad. The bit I had most concern with was the very start in much the same way. The approach is constructive. We talked about how much work we want to give them. Not sure we have consensus on the use case.
Jeffrey: happy to redraft first paragraph
Matthew: the fedid people want to pull login providers out of the webpage and into the browser. Is this a stepping stone to that?
Jeffrey: the way fedcm works in chrome is it sticks this sort of information inside of the content area in a way that we should dislike. The shape of the api would allow a browser to pull it out of the content area, but the implementation hasn't done that. We should say something about fedcm, connected to this issue. But it's also separate, it's a UI choice chrome has made not required by the api shape.
Peter: if the use case is knowing you've provisioned google pay or apple pay, isn't that provided by th epayment request api?
Tess: there's a query method to ask if a payment method is supported. That will not say is a card provisioned at apple pay or not. Don't think there's api to tell you there's a card provisioned. Fingerprinting risk.
Peter: is there a way to provide functionality to the user without exposing it to the webpage
Tess: payment request.. you get the UI.. at that point when you see that screen you'll know if you've provisioned a card or not, because it'll be filled out or it won't. They're trying to shortcut that.
Peter: have you already selected the payment provider at that point?
Tess: depends on the browser. In Safari Apple Pay is the only payment provider supported. In a browser that supports others you'd have to have a way of selecting them.
Peter: presuming there's multiple if the browser is going to present the ui to choose the payment method, the browser can tell the user which is provisioned..
Tess: depends on the relationship between the browser and the payment method and the apis available, it might not have any way of knowing
Jeffrey: Shopify wants this and are not a payment provider
Peter: in general we tend to recommend instead of a broad api that exposes user information in js, just use this platform api and let the browser handle all of it. I'd like to have that response here. Just use payment request api, solve them in payment request. If there's a problem why you can't use payment request, let's fix payment request
Jeffrey: that has not been convincing to the payment providers. My impression is they don't want to outsource their UI to the browsers. When we force them to they have specific requests about what exactly the UI should look like becuase of their legal teams.
Peter: this is the payment providers
Jeffrey: Stripe and friends
Peter: that would be handling the transiaction.. are not wanting to work with the browsers?
Jeffrey: they did work with us in the context of the webauthn integration. They had to. They insisted in precise language in the opt outs inside the browser UI. That was for one piece of their authn flow. Getting the entire payment flow into the browser will be even more of that.
Peter: disappointing but understandable. That would be the better direction, rather than opening up other weird escape hatches.
Jeffrey: we are suggesting this might be attainable by sticking some UI into the browser chrome rather than the page. Of course it's a security problem if the page controls what's in the browser chrome
Peter: not the content, but the page can influence what gets to show up by opting into different providers
Jeffrey: folks also wondered if the actual attack we're worried about is reasonable for payment. If we stick the credit card number in the page is that likely to trick users into thinking the've given the page their credit card number already and will that change their behaviour?
Tess: we know it does because they're justifying this api on that basis
Jeffrey: but is it because it's tricking the user? they can do research to answer that and they should. Not obvious which way it comes out.
Peter: even if you say overwhelmingly it's just a confidence thing, there will be some people who think they've been there before and it's saved their card
Jeffrey: what fraction of tricked users is acceptable
2024-11-04
Jeffrey: Martin wrote a draft comment...
Peter: we did discuss at the Seattle f2f...
Yves: we concluded that it was a potentially deceptive pattern - you may feel you have done business with these people...
Jeffrey: the core use case is telling the user that clicking this button will do something for them - prefilling credit card number, for example.
Peter: how do you enable a feature like that in a way that is not deceptive.
Tess: put the info that is cross-site outside of the viewport. People don't have a mental model that includes iframes...
Jeffrey: I'll propose some new text...
Dan: would an alert in the browser chrome make sense?
Jeffrey: we can ask the proposers for user research that indicates why there has been a change of behaviour (e.g. increase in "conversion")
OpenedJul 10, 2024
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:
What should this questionnaire have asked?
N/A