#975: Fenced frames with local unpartitioned data access
Discussions
Log in to see TAG-private discussions.
Comment by @hober Aug 20, 2024 (See Github)
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?
Comment by @shivanigithub Sep 6, 2024 (See Github)
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!
Comment by @shivanigithub Sep 6, 2024 (See Github)
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" https://github.com/w3ctag/design-reviews/issues/735 which was resolved positively
- "specification review" https://github.com/w3ctag/design-reviews/issues/838
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.
Discussed
Oct 1, 2024 (See Github)
[mt] This is a terrible idea.
Discussed
Oct 1, 2024 (See Github)
Looking to close with unsatisfied. Martin will draft something that will likely be very spicy. Jeffrey will help make that less overtly offensive.
Discussed
Nov 1, 2024 (See Github)
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
Discussed
Nov 1, 2024 (See Github)
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")
Discussed
Nov 1, 2024 (See Github)
Jeffrey: I don't think we're ready to post a position yet ... Martin and I have been going back and forth on this ... concerns about the use cases ... many TAG members seem to be OK with the "NASCAR" use case - i.e. removing the need to have all the payment type buttons. But we might have to just say there's disagreement on the use cases / disagreement on the solution...
... then there is a question of what to do with the overall fenced frames feature - don't know what the use cases are without this (#838) or protected audience. #975 is one of the uses for fenced frames ...
... don't think fenced frames relies on protected audience but another use supports protected audience ...
... one thing the developer team might come back with - is a general argument embedding in the web ... "we want to do authenticated embeds" and the TAG might say "unpermissioned authenticated embeds are bad". Storage Access and FedCM as alternatives - "do we have permission to join your identity".. We don't have a solution for embeds that don't join identities.
Hadley: I think we havea fundamental problem with it...
Jeffrey: I see a use case for an embedded google doc - if the UA is incharge of the UI... If you don't let the embedded page knowledge... Render the embedded page as if it were top level - and that it's not exposed to the surrounding page.
Hadley: isn't that still partitioned?
Jeffrey: yes that's .. segregated data .. supposed to act like it's partitioned. The thing we're worried about is showing the other partition inside of the current page. If the UA rendered a google docs document as if it's a top level navigation and placed it in the ... top level area of another page - maybe the UA could do something that's sufficiently clear... Not sure that would work but it seems the most plausible...
Discussed
Nov 1, 2024 (See Github)
Jeffrey: Martin, I'd like to know more about what you think are the use cases? What do you hate about tbe nascar thing?
Martin: nothing in the soultion allows us to distinguish between that use case and the abuse cases. This seems to enable abuse and doesn't enable the things I think I care about. Nascar: you ahve to log in with one of the 500 different id providers, and you have to find it out of this giant grid. We have a solution for that: FedCM, and the browser knows which of those identities you have.
Then we don't have all the abuse and deception.
Jeffrey: so the idea is represent all the payment and this provider has some info to fill in treat those login cases?
Martin: or similar. Different flow for payments, but yes.
Jeffrey: I can put in suggested comment.
Martin: whether or not this is so bad we object? I would. Not sure if we have consensus there
Jeffrey: I don't think there's a problem with saying this solution is objectionable. I was trying to phrase it effectively.
Martin: there is a piece of the problem that is useful. We should focus on that.
Talking about web payments and fedCM -- examples of where the browser can mediate these things. constructive way to do it.
Comment by @jyasskin Nov 27, 2024 (See Github)
The TAG agrees that it would be useful to enable the user-focused use case here. Specifically, the web is in the situation that sites show a list of third-party providers, each of which might or might not be able to help the user sign in, pay, or perform some other function on the main site. The user may not remember which of those providers they've stored the relevant data with, and it's frustrating to click one of these buttons only to find that it can't help you. In a browser with 3p cookies, those buttons can give an indication of what data they have access to, but as browsers phase that out, this sort of button can no longer provide these capabilities. It seems useful to try to prevent that frustration, if doing so is possible without confusing users about what identity they've already presented to the main site.
The explainer is very unclear about whether that use case is actually the fundamental goal of this proposal. If the explainer is literally correct that the goal is to "decorate a third-party widget with cross-site information about the user", we think that's very likely to be a harmful goal and incompatible with our work on privacy principles for the web.
Even if we've correctly understood the use case, we think the proposed solution in this feature makes it too hard for users to correctly infer who already has access to that information. If a user incorrectly infers that the containing site already knows their identity, they're more likely to then "agree" to share their identity with the site, violating the privacy principle on identity. The two concrete examples of when to use this feature appear to be causing this sort of mistake in practice, whether or not their designers intended the deception.
For example, Google Accounts presents a login chip on a number of websites (such as Reddit). Some versions of this chip show your Google account name, profile image, and email address. Several members of the TAG have concluded from this UI that they had already used Google to log into a site, even though they hadn't. We then clicked through the login chip, creating a connection between Google and the site that we hadn't intended or wanted. Even if it wasn't intentional on the part of the UI designers, this had the effect of reducing our autonomy. FedCM seems like a better solution for login than letting the providers embed cross-site data.
Google Pay implemented a button that presents the last four digits of a credit card, taken from the last transaction with that service, even if the transaction was elsewhere on the web. This greatly improved the rates at which people completed a purchase. However, we're concerned that, like in the login case, this increase in purchases might be happening because users incorrectly concluded that they'd already bought something from the active site, and we haven't seen UX research that explored users' beliefs in this case. Further work on Payment Handlers might be a better way to expose this sort of hint.
We don't mean to imply that Google is unusual in these practices. These techniques lead to better business outcomes for websites and their service providers, and it's perhaps unsurprising that neither group has checked what fraction of users are getting the outcomes they want. But we need that evidence before considering this UI in user agents. And these are just the relatively benign cases: once a browser removes 3p cookies, truly malicious actors have a much stronger incentive to find ways to trick users into joining their identities (see some ideas in https://github.com/WICG/turtledove/issues/990). This proposal doesn't analyze or protect against that risk.
One might argue that the proposal is ok because it just allows websites to give their users false beliefs, and a user has to still separately consent before their private information is released, but as far as we can tell, identities can be joined as soon as the user clicks, which isn't sufficient for the browser to know they've consented. Even if there were a separate consent screen, its task seems very difficult, needing to both explain what the user's being asked to consent to, and override anything the user's been convinced to believe about what information the site already has.
We suspect that embedding information from a different context inherently enables deception about the surrounding site's knowledge. Certainly embedded sites could do the work of explaining what information their embedders already have, but we've seen that the default behavior is not to do that, and we haven't seen either what malicious actors could do with this when motivated, or a creative analysis of the worst abuse cases. If you intend to pursue something akin to this general approach, a thorough analysis of the ways in which this might be abused and mitigated is essential.
We want to reiterate that the core use case seems valuable to solve, and we encourage you to keep trying to solve it. To do this safely, we suspect that you'll need to show the available information in browser UI, rather than inside the content area.
Comment by @shivanigithub Nov 27, 2024 (See Github)
One might argue that the proposal is ok because it just allows websites to give their users false beliefs, and a user has to still separately consent before their private information is released, but as far as we can tell, identities can be joined as soon as the user clicks, which isn't sufficient for the browser to know they've consented. Even if there were a separate consent screen, its task seems very difficult, needing to both explain what the user's being asked to consent to, and override anything the user's been convinced to believe about what information the site already has.
Could you elaborate on the understanding that a click would be sufficient for identities to be joined with the fenced frames solution? It's an explicit design goal to not be able to exfiltrate the data read within the fenced frames to the embedding page or to the network. Post-click, the embedding context knows there was a click and the action they take would be independent of what was displayed in the fenced frame, e.g. opening a new pop-up or invoking PaymentHandler etc.
Comment by @martinthomson Nov 27, 2024 (See Github)
As I understand it, something happens when someone clicks on the frame. So there is a difference between an outcome where someone clicks and when someone doesn't. The embedding contexts learns about whether there was a click.
If the content shown can affect whether a click occurs, then the embedding context gains information. In the extreme, you might imagine content in the frame that guarantees a click in one case ("click here to enable this free addon") and guarantees no click in another (leaving the area blank or "click here to agree to something awful"), then the information carried by that click (or absence thereof) is high. Maybe it's not perfect, because people are often perverse like that, but you have created a means of exfiltration.
https://github.com/WICG/turtledove/issues/990 goes into more detail about the sorts of things you might do to gain information from the human involved.
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