Re: [w3ctag/design-reviews] Eligibility for autofill (Issue #831)

Hey folks. We've been discussing this situation among a few experts in the Chrome team and we think the fundamental big-picture challenge here is that an `<iframe>` implicitly indicates a 3P is trusted to both present information (draw pixels) and collect information (input) potentially even highly sensitive information with no ability to separate these concepts. This is particularly problematic given that 3p iframes are used extensively for use cases that absolutely should not be trusted to collect PII (ads) and for those that should (payment forms).

Ultimately users can really only reason about a trust relationship with the top-level origin (what's displayed in a URL bar) and that origin needs the ability to delegate trust appropriately to it's 3P dependencies. This is pretty obvious with behavior like popups, going fullscreen, etc. But autofill is fuzzy - not really a platform feature on it's own, but a UA feature for helping to automate the platform feature of accepting input from the user (as @annevk has pointed out). 

So we're thinking perhaps the right long-term model to be aiming towards here is having sites indicate which of their 3P dependencies have a legitimate reason to accept PII from the user at all (credit card numbers, phone numbers, e-mail addresses, etc.?). So perhaps instead of a `shared-autofill` permission policy, we'd introduce a more generic `pii-input` permission policy. It would mostly be up to UA implementations to decide what additional protections to offer users when they seem to be entering PII into a 3P iframe that hasn't been marked as trusted to accept PII, but we could spec such a policy as a signal to the browser to treat the 3P as it would the 1P for any such purpose (with the normal permissions policy argument that an embedding site could always implement it via a postmessage channel anyway - so better to just let them state the trust declaratively). We wouldn't be proposing any particular breaking change here, but such a policy would open the door for UAs to reasonably start warning about questionable PII disclosure practices (perhaps even manually typing a credit card number into a sandboxed iframe) with the help of an explicit API for embedders to indicate the trust they have in their 3Ps for disabling such warnings.

In Chrome we already support an [`identity-credentials-get` permissions policy](https://fedidcg.github.io/FedCM/#identity-credentials-get) for indicating when a frame should be trusted to use the FedCM API to collect identity information. We now think that was probably overly specific, and we could migrate that to `pii-input` as well. After all the threat is all about collecting PII under the top-level origin and so whether the user is typing their e-mail address or logging into their e-mail provider, the principle is the same (though of course UA impl details may differ given the practicality of web compat).

For the extent to which folks decide it makes sense to specify aspects of autofill (eg. @annevk seems OK with having an "eligibility for autofill" section in HTML), we could include this `pii-input` policy in the definition. In the long run we'd love to be able to say that autofill is never enabled on frames that lack `pii-input`, but taking steps in that direction would need a careful breaking change plan and so is something we'd aim to work towards over an undefined timeframe.

Any thoughts on this high-level design framework? @schwering has been trying to address this payments use case for upwards of a year now so I don't really want to slow him down further, but he's agreed to reframe his proposal in this direction if y'all agree with me that it's a better long-term vision to be taking a step towards here. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/831#issuecomment-1702946884
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/831/1702946884@github.com>