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

Hi folks, resurrecting this :-).

We've generalized the proposal to addresses the problem of (text) input in 3P documents.

As @RByers  wrote [above](https://github.com/w3ctag/design-reviews/issues/831#issuecomment-1702946884):

> 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. [...] 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.

In this spirit, we're proposing [two policy-controlled features](https://github.com/explainers-by-googlers/safe-text-input) by which the embedding document can limit an embedded document's ability to receive text input.

These features are non-normative hints that text input may be unsafe. The browser can use them as signal to warn the user or even suppress the input events in the embedded document. We'd want to roll this out carefully to avoid breaking changes, with the long term vision of default-disabling text input in 3P documents.

We propose *two* policy-controlled features:
- one for autofill ([explainer](https://github.com/explainers-by-googlers/safe-text-input/blob/main/autofill.md)) and
- one for keyboard etc. input ([explainer](https://github.com/explainers-by-googlers/safe-text-input/blob/main/manual-text.md)).

The difference between the two is that autofill may target multiple documents at once. That is, a document may receive autofill input without the user interacting with that document directly. We think this presupposes a greater level of trust than, say, keyboard input, and therefore requires a separate policy-controlled feature.

I'd be curious to hear the TAG's thoughts on this revision!

The proposal has of course changed quite a bit from what this TAG review was about initially. Happy to file a separate a issue if you prefer.

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

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