search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
319 stars 55 forks source link

Eligibility for autofill #831

Open schwering opened 1 year ago

schwering commented 1 year ago

こんにちは TAG-さん!

I'm requesting a TAG review of shared-autofill.

Payment service providers (PSPs) often distribute form controls (e.g., credit card number, CVC) over multiple distinct PSP iframes on a merchant checkout page. We propose a same-origin policy for autofilling such frame-transcending forms. Additionally, some less-sensitive fields from a PSP point of view (such as cardholder name) are often part of the main merchant frame instead of inside PSP iframes. For this case, we propose a policy-controlled feature which allows a parent frame to designate child frames as trusted for the purposes of Autofill, irrespective of their origin, allowing the browser to fully fill such cross-frame forms.

Further details:

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @schwering, @stephenmcgruer

Questionnaire

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

Our proposal restricts which origins a browser may share Autofill information with.

The HTML standard currently does not specify which kinds of information are shared, which user action (if any) is necessary to share the information, and which origins the information may be shared with. Most browsers display a list of suggestions when the user interacts with a form control, and they share the selected information with the form control’s document when the user confirms a suggestion.

We propose to restrict this information sharing to documents which either have the same origin as the form control the user interacted with or have the newly proposed shared-autofill enabled. As a policy-controlled feature, only the first party can enable shared-autofill in child frames.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes, our proposal minimizes the scope the information is shared. It will improve transparency in the following way.

Today’s browsers do not fill across origins. Many payment service providers work around by posting autofilled information from one frame to other frames using postMessage(). Naturally, such workarounds break the preview of to-be-autofilled information built into many browsers. Our spec makes such workarounds obsolete and lets the browser preview and autofill form controls in cross-origin form documents (if shared-enable is enabled in the respective document).

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

Our specification fills a gap in formalizing the conditions under which the browser may fill such information.

Our proposal allows sharing such information according to a same-origin policy and a newly proposed policy-controlled feature shared-autofill, which can be passed by parent frames to their child frames to designate such frames as trustworthy for autofill purposes.

As argued in 2.2, our proposal intends to make JavaScript workarounds obsolete and increase transparency.

2.4 How do the features in your specification deal with sensitive information?

See 2.3.

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

2.6 Do the features in your specification expose information about the underlying platform to origins?

No.

2.7 Does this specification allow an origin to send data to the underlying platform?

No.

2.8 Do features in this specification enable access to device sensors?

No.

2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

2.10 Do features in this specification allow an origin to access other devices?

No.

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No.

2.12 What temporary identifiers do the features in this specification create or expose to the web?

None.

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

The first party can enable shared-autofill in third-party child frames, and these child frames in turn can enable shared-autofill in their respective child frames. This behaviour is due to shared-autofill being a policy-controlled feature.

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

The proposal is unrelated to private browsing or incognito mode. A browser may decide to disable Autofill in such a mode.

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

It doesn’t have sections with these titles, but it does have a section on attack vectors.

2.16 Do features in your specification enable origins to downgrade default security protections?

There are currently no security protections for Autofill. This proposal introduces default protections, as well as a policy-controlled feature that is disabled by default for cross-origin iframes.

2.17 How does your feature handle non-"fully active" documents?

Our specification excludes non-”fully-active” documents.

2.18 What should this questionnaire have asked?

It seems sufficient.

torgo commented 1 year ago

Hi - can you clarify where this work is currently happening? Is this slated to be done in WICG? Has there been any engagement on this topic with other engines / browsers?

cynthia commented 1 year ago

Thanks for bringing this to our attention. We looked at this during our F2F, and overall we are happy with this. It solves an immediate user need, which is being able to autofill cross origin forms, which as far as the user is concerned should work like any other form.

We have a couple points we'd like to discuss here, both of which are likely out of your immediate control but would like to see some progress on.

1) Interest from other implementors. This seems like a useful, safe feature which would be more powerful if at least one other implementor is interested in implementing this (setting aside the depedency on permission policy, which is a dependency). 2) We do see the immediate reason why multi-frame forms is a thing, but we would like form domain experts to think about a future direction where we move away from this somewhat convoluted architecture. We understand the proposal is working around layers of limitations, but we feel like it shouldn't be this way. 3) In an ideal world, the solution to (2) might be web payments.

hober commented 1 year ago

As @annevk said elsewhere, autofill "is a user interface feature and as such the call as to whether or not to make it work in a particular case is with the user agent and not the HTML Standard." If some browsers' autofill doesn't work with fields in Shadow DOM, for instance, that seems like a bug in such browsers, and not with the spec.

schwering commented 1 year ago

Thank you all for the feedback and comments!

Re @torgo

We intend to pursue this in the WHATWG as part of the HTML spec, and are looking to drive consensus on the autofill definitions within that group.

Re @cynthia

  1. The final positions on the proposal from Mozilla and Apple are pending and discussions are ongoing.
  2. We agree. We suppose this would need cooperation of the implementors, payment industry, and payment service providers.
  3. Acknowledged.

Re @hober

Thanks Tess (and Anne!); we do appreciate and agree that autofill is a user interface feature. However, we think there is value in giving web developers some structure around what they can roughly expect, and in particular we think specing shared-autofill as a clear (though non-binding) signal to the browser is valuable. Much like how autocomplete="cc-number" is a valuable signal for web developers to know about.

We're happy to work with Anne to find the right middle-ground of what to spec – see our latest reply in the WebKit request for positions where we changed the text, and we can keep iterating on that!

torgo commented 1 year ago

Hi folks – We discussed this in today's TAG breakout.

We remain concerned with the level of information available to the user about what they have agreed to share with whom via auto-fill. Is it possible to advise UA providers to surface this information to the user in some way "are you OK with sharing your cc number with ecommerce site who uses payment provider as a payment provider?"

We also remain concerned about the multi-stakeholder buy in. If this is going to be adopted by the industry then we'd like to make sure it's widely adopted across browsers.

Apart from that can you let us know any other status or updates?

schwering commented 1 year ago

Hi Daniel,

We remain concerned with the level of information available to the user about what they have agreed to share with whom via auto-fill. Is it possible to advise UA providers to surface this information to the user in some way "are you OK with sharing your cc number with ecommerce site who uses payment provider as a payment provider?"

We've considered this, but in the use-cases we see so far, we believe this wouldn't help the user in the frame-transcending (payment) forms we see today. There's a large number of payment service providers (900+ according to Wikipedia). And the PSP origins are often hard to recognise because they tend to be quite bulky (some examples: assets.braintreegateway.com, secure-magenta1.be2bill.com, checkoutshopper-live.adyen.com, request.eprotect.vantivcnp.com, epgjs-rendercashier.easypaymentgateway.com).

We also remain concerned about the multi-stakeholder buy in. If this is going to be adopted by the industry then we'd like to make sure it's widely adopted across browsers.

We don't have explicit statements from WebKit or Mozilla.

However, payment service providers have voiced their interest. Happy to ask them to chime in here if you feel this is relevant.

Apart from that can you let us know any other status or updates?

I think the HTML PR is close to getting approval. We've extended the example and note to elaborate when and why a browser many decide to fill across iframes.

torgo commented 1 year ago

Hi @schwering

However, payment service providers have voiced their interest. Happy to ask them to chime in here if you feel this is relevant.

I think it would be good to understand the feedback and "pull" from relevant stakeholders (i.e. service providers). We'd also suggest requesting feedback from the Web Payments working group if that's not something you've done already since this is so squarely in the payments space? Looping in @ianbjacobs on this.

stephenmcgruer commented 1 year ago

We'd also suggest requesting feedback from the Web Payments working group if that's not something you've done already since this is so squarely in the payments space?

Putting on my Web Payments WG hat for a moment (whilst acknowledging I also work for Chrome/Google, and alongside @schwering on this proposal):

A desire for autofill to work better for payment forms is definitely common feedback I have heard from payment service providers (PSPs). I would say they have two main needs:

  1. Adhere to security best-practices and regulations on processing credit card information (particularly PCI DSS). This results in a need/desire to isolate the merchant from card data (credit card number and CVC being the most sensitive), which is why it is common for PSPs to offer credit card input fields isolated inside of iframes (such as Stripe Elements or Adyen Components*).

  2. Meet their merchants' needs for customization of the provided checkout flow primitives, such that a merchant can build an experience that matches their own brand. This leads to a few sub-needs, including:

    • Separate iframes for each field (cardholder name, credit card number, expiry, CVC), so that the merchant can arrange and style them as needed.
    • Some less-sensitive fields to be owned by the merchant (most often cardholder name), since the merchant may need this data directly for e.g. aligning with shipping info.

From a Web Payments WG perspective (but not speaking officially on their behalf), we certainly believe that this status quo is not desirable, and we have long tried to build APIs in what we think is a better direction such as Payment Request (and the now-deprecated basic-card payment method) and Payment Handler. However we also should recognize that so far we have not strongly succeeded in our efforts, and in my opinion we should also meet the industry where it is at (and provide better services to users on the web!) where needed. As such, I personally would hope that the Web Payments WG would support this effort.

* These are intended as examples only and do not imply specific endorsement of this idea from Stripe or Adyen. As @schwering noted, we can ask for official statements of support from PSPs be provided if desired by the TAG.

stephenmcgruer commented 1 year ago

(Chrome hat back on)

I'm interested to understand the TAG's concerns a little deeper. I can see three main scenarios where data-sharing may be a concern:

  1. User initiates a fill on https://main-frame.example, and due to the shared-autofill permission policy proposed here, the browser fills some info down into fields in https://iframe.example (which the main-frame has given shared-autofill to)
  2. User initiates a fill on a frame https://frame.example, and due to the same-origin autofill model proposed here, the browser fills across to fields in other https://frame.example frames (could be iframes, could be main frame).
    • To me this shouldn't be a concern, because these same-origin frames could just postMessage to each other anyway.
  3. User initiates a fill on https://iframe.example, and for some less-sensitive info, the browser fills some data 'up' into fields on the main frame https://main-frame.example
    • I can see this being a concern, as that the user is technically sharing info with site A and the browser is silently sharing the data to site B
    • However, this seems like more of an 'iframes are generally scary' concern, in that as a user you basically never know if particular content (or a text input!) you see on a page is from the main site or an iframe it has embedded. The web roughly requires that you transitively trust the main-frame to not embed things that might try to trick you!
    • Put another way, we don't warn users when they type information into an input field that is inside an iframe, or just hit a keyboard key when an element inside an iframe has focus. This doesn't seem fundamentally different.

As a side-note, to me there is also the practical consideration that autofill already exists today as a browser feature on multiple browsers, some of which are doing behavior like this. Autofill is also mostly un-specified and non-interoperable across browsers, which makes it opaque/difficult for website developers. Whilst it looks like fully standardizing it will be unlikely to happen (Apple have stated that they consider it a browser feature), I think it would be positive for website builders and the web if we could standardize at least some sub-part of the behavior for them to rely on!

ianbjacobs commented 1 year ago

@schwering and @stephenmcgruer, although you have likely already received input from some stakeholders, would you be interested in a presentation of this work at an upcoming WPWG call for additional feedback or expressions of support? (We could make a special effort to get PSPs to attend that call.)

stephenmcgruer commented 12 months ago

@schwering and @stephenmcgruer, although you have likely already received input from some stakeholders, would you be interested in a presentation of this work at an upcoming WPWG call for additional feedback or expressions of support? (We could make a special effort to get PSPs to attend that call.)

@ianbjacobs - I'm happy to, or to support @schwering in doing so. We do already have input from multiple PSP stakeholders, but always happy to hear from the WPWG too :). I'll follow up with you via email.

torgo commented 11 months ago

Hi @stephenmcgruer - thanks for your comprehensive and thoughtful responses. Indeed, it's scenario 3 that we're concerned about. Granted, this is a behaviour already associated with iframes, however we're talking about users' credit card details being auto-filled into these iframes so I think this deserves some additional scrutiny. From a "leave the web better than you found it" point of view, how his this feature making payment autofill more secure and more transparent to the end user?

ianbjacobs commented 11 months ago

The Web Payments WG will discuss at their 3 August call: https://github.com/w3c/webpayments/wiki/Agenda-20230803

stephenmcgruer commented 11 months ago

Hey folks; sorry for the delay here in replying. Starting with my WPWG hat (will reply with my Chrome one following :D):

The WPWG discussed this issue at our August 3rd call (minutes). Overall, we heard the following main points (my own summary):

Attendants of the meeting included representatives from a few merchants and the Merchant Advisory Group, some credit card networks, some PSPs, and the PCI Security Standards Council. This list does not mean any particular entity approved of the proposal outside of what is captured in the minutes, but just to give an idea of what the audience was.

stephenmcgruer commented 11 months ago

Now putting on my Chrome hat :)

We believe that the WPWG discussion shows significant need and interest, which aligns with what we have previously heard from other specific payment industry members. In the WPWG discussion (although not captured by the minutes, so of course treat with distrust ;)) we also covered that whilst the WPWG believes in finding 'better' (smoother, more private, more trustworthy) solutions for payments on the web, the group also acknowledges that payment forms are a huge part of payments that is going nowhere soon - and addressing pain points there has value for both web users and the businesses.

I think there are two points we need to speak to - firstly, one suggestion from the WPWG comment, and secondly the outstanding TAG comment re sharing 'upwards'.

WPWG suggestion to constrain shared-autofill

In the WPWG discussion, there was a suggestion to constrain shared-autofill if possible, e.g. to be able to say "I trust this iframe, but only for payments, don't give them addresses".

Although we support the idea of trying to constrain in this way, we don't think it is currently feasible:

  1. There are no broad categories of autofill types specified today, and the path to specifying them seems unclear given autofill's historical status as a browser feature. It happens that Chrome generally defines our supported autofill types as 'addresses', 'payments', or 'passwords' today - but that's a purely internal splitting and is subject to change (and there are fuzzy boundaries too, e.g. your name could be both payments or address data!).

  2. The autocomplete attribute does give some very specific types (e.g., cc-number), but those are incomplete today - that is, browsers recognize more types of data than are expressable via the autocomplete attribute. In Chrome we're working to correct that (e.g., we have ongoing work for specifying more address-related attributes, and also are looking at specifying things like IBANs), but there will almost definitely always be a race where new types are heuristics first, then formally specified later.

  3. More technical (rather than ideological), this isn't (I think?) currently possible with the permission prompt syntax - there isn't a way to specify sub-tokens of a permission prompt type. We might be able to introduce a very long list of permission prompts as a hack, e.g. shared-autofill-cc-number, shared-autofill-house-name, etc, but this would get very unwieldy for developers.

As such, Chrome's current position is that we are sympathetic to this idea, but do not believe it feasible/practical. We are open to hearing ideas if anyone has them!

TAG's recent comment on the 'fill upwards' angle

This comment, where @torgo relayed the concern on sharing less-sensitive data upwards from a fill initiated on an iframe to the main frame.

We appreciate the input and do acknowledge the responsibility to leave the web better. We think that this proposal is still an improvement over the status quo, as the only tool for developers to achieve this today (without browser support) is to postMessage from the iframe to the main frame. When developers do that, the sharing is invisible to the user, whereas with this proposal the browser is able to show an autofill preview that helps the user understand what data is being filled. (We acknowledge that preview will not make it clear to the user that this sharing is across frames, because generally iframe boundaries are invisible to them already).

We also note that the proposed spec text already allows for a user agent to not fill a given field, and also that nothing prevents a user agent from choosing to display a warning to the user if it desires. If the TAG thinks it would help, we could add some note to the spec advising user agents to consider this angle, but we think it should be at most advisory and not a formal should requirement.

We look forward to a reply from the TAG, and thanks again for your patience and input!

torgo commented 10 months ago

Hi Stephen - thank you for this really clearly written summary and response to our feedback - it's greatly appreciated! We discussed again in today's TAG breakout. We're still concerned that this is a stop gap in anticipation of WPWG coming up with a better long-term solution? Do you have an idea for how we can stop the stop gap from becoming the de facto permanent solution?

stephenmcgruer commented 10 months ago

Thanks Daniel. Speaking not on behalf of the WPWG here (I'll let @ianbjacobs answer from that perspective, if he wants), I see a few angles on this myself:

  1. Firstly, market forces. In general, credit card forms are declining as a percentage of payments on the web (though they're still a large chunk, which is why this is worth doing!!), especially in non-US markets. They're being replaced by payment wallet apps (e.g., PayPal, MomoPay, ApplePay - varies wildly by geography), by Buy Now Pay Later apps (which are basically a form of payment app), and by government-backed schemes such as PIX, UPI, or PayNow.

    1. For the payment apps, we on Chrome have long invested in trying to make this market work better for both users and developers, with our continued investment in Payment Handler to support an open ecosystem of wallet apps. This strategy is still struggling to be frank, but we're committed to it and would love to see it develop further.
    2. For the new government-backed schemes, I personally would love to see the WPWG involve itself further in how the web might better support these schemes - where commonly today they are heavily QR-code and app-based. In Chrome, we have some ideas percolating on how to support better integration with the open web, and will share those with the WPWG as they solidify.

  2. For credit card forms themselves, I personally still believe that Payment Request and the 'basic-card' payment method was the right idea, just perhaps executed wrong. I would like to see a future where we give websites an API to access the users billing and payment details (with the users express permission and clear UX, of course!), but where we address the concerns that merchants had with basic-card. I'm honestly not sure how to advance that future in the WPWG at this time; but from our side we'll keep sharing ideas :).

I hope that is a reasonable answer - I know point (1) is sort of a 'side step' but I truly believe the market forces matter a lot here! :)

RByers commented 10 months ago

Hey @torgo, if I understand the concern the TAG has here, it's not restricted just to any cross-document filling cases, right? In the simple case of a 3P iframe with a field that the user clicks directly on, your concern would also apply there too. Is that right?

I suspect that's where the gap is here. @schwering is focused on the scenario of cross-document autofill (taking the established behavior of same-document autofill as fixed) but I think TAG is raising a good point that we should take a step back and think about articulating and possibly improving the security model for autofill in 3p iframes generally (even the simple single-document case). Is that right?

RByers commented 10 months ago

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 accessing the microphone, 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 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 accessing the user's identity under the guise of 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.

ianbjacobs commented 10 months ago

Just a note: we can make time on Monday or Tuesday at TPAC at the WPWG meeting to discuss this if people would find that useful. (Tuesday afternoon is particularly good.)

RByers commented 10 months ago

Thanks Ian. I'll be there and happy to present for such a discussion if there's interest.

RByers commented 9 months ago

A few of us met at TPAC to discuss this: @torgo, @stephenmcgruer, Gerhard Oosthuizen, @cynthia and myself. Here's my summary of the conversation, please let me know if I missed or mis-recalled anything.

First Dan said the TAG wanted to understand how we could help web payments shift towards something better than forms long-term. We all agree that entering strings into text fields is a sub-optimal user experience for completing a payment. @stephenmcgruer described the many years of efforts from WPWG and others, and how the industry is continuing to shift towards payment apps - whether via PaymentRequest or some other mechanism on top of web platform primitives. We talked a bit about things we may (or may not) be able to do to further accelerate a reduction on reliance of input fields, but I think there was agreement that input fields weren't going to just go away anytime soon. Certainly @stephenmcgruer and I intend to continue investing in approaches in Chrome to help meet the needs of the payments industry outside of input fields, but feel we need to address this tactical and pragmatic issue with payment forms in parallel with that.

Secondly we discussed my proposal above to shift the policy away from a nuanced implementation detail of autofill (shared-autofill) to more of a trust model for the embedder/embedee relationship around collecting user data. We heard that pii-input was a bad name because "PII" has a very specific legal meaning we wouldn't want to confuse things with. Otherwise Dan said he'd like to discuss this more with the TAG and get back to us ASAP.

On Chrome, we'd like to proceed with some urgency in this direction. Our current thinking is that we'll update our proposal to use the permission name input but defined in a way that gives the user agent latitude in deciding which forms of "input" are risky enough to disallow in frames lacking this permission. Frames with the input permission would be expected to accept all forms of input exactly as if they were operating in the top frame. In Chrome we'd start by only gating new automated input scenarios like shared-autofill on the input permission, but over time we'd explore whether there are existing classes of input we could begin to warn about or restrict when this permission is lacking. We welcome feedback on this approach, and I'll post pointers here as we proceed down the path of trying to ship this.

torgo commented 9 months ago

Hi @rbyers - Discussed briefly today and there is rough consensus that this is the right approach. We'd like to see it written up in a revised proposal – is that in the works?

RByers commented 9 months ago

Great, glad to hear it @torgo! I'm personally excited about taking steps towards making the web's model for user data acquisition more explicit...

Yes @schwering is working on an updated proposal but it may be delayed a bit now as something more urgent came up for him. We'll ping this review whenever the explainer and spec PR have been updated. But also this is really just a change of positioning / long-term goal (and policy name) with the immediate next step otherwise unchanged.

hadleybeeman commented 9 months ago

Hi @RByers! Just to clarify, after a quick conversation at our plenary meeting today — we would appreciate it if you could explore some abuse scenarios in your updated proposal. We had some concerns, and would really value your thoughts on how to mitigate any potential problems. Huge thanks!

RByers commented 9 months ago

Hi @hadleybeeman, do you mean improving on the existing attack vectors section of the explainer which focuses on how the narrow case of autofill split across frames could potentially be abused? Or do you mean broaden the abuse discussion to autofill in 3p iframes generally (i.e. status quo in multiple browsers) and how the new proposal gives a path to potentially reduce that risk over time? Or maybe both?

torgo commented 7 months ago

Hi @rbyers - we just discussed in TAG plenary today and I think what we're asking for is more the first thing - expansion on the existing attack vectors discussion - although in my view "attack vectors" may be too narrow a framing. What we're concerned about is general abuse scenarios of this new proposal: given that this new proposal is in place, what are the abuse scenarios, including by actors who may be "legitimate actors", and what are the mitigations against those? In other words, how may this be mis-used by players in the web ecosystem?

torgo commented 1 month ago

Hi @rbyers - we were just briefly reviewing status on this. First of all, has there been any update that we should be aware of? Should we be re-reviewing at this point?

schwering commented 1 month ago

Hi Daniel! I'm currently revising the proposal, broadening its scope from autofill to (keyboard) input in iframes. I'll update the thread here when I have something to share.