cc'in  zkoch@ and sabineb@ for more insights.

Adding a couple more folks.

It does seem to me that "Autofill" should be the most important checkbox, so if that's disabled, all "Autofill" should be disabled (i.e. CC, Addresses, Passwords). But might be missing something.

(Cc-ing vasilii@ in particular for point (3) below.)

Thanks for raising this, I see a couple of interesting issues to look into:

(1) The name "autofill" becomes confusing -- in the settings (and crbug component names, for that matter), we use it to mean all but the feature which fills passwords. Confusingly, the only type of data which is automatically filled (under some circumstances) are passwords. Unlike addresses, credit cards, single text-input fields which are always only filled after the user selects a suggestion in Chrome's UI, passwords can be autofilled on load (except in Incognito, when matching across public-suffix-list-related origins, etc.).

So while our intention was for the "autofill" checkbox to mean: "all form filling except for passwords", it sounds more like "disable the 'automatic' part of form filling", which is not currently possible in Chrome.

(2) The checkbox for passwords ("Offer to save your web passwords.") indeed only controls saving, not filling. The idea is that storing a password is a potentially risky operation, and needs to be compensated by its usefulness (the user has a copy of their password stored, but then gains security through this password being potentially unique, strong and only filled on the correct origin). So having a stored password has not much sense without being able to fill it. Chrome is trying to keep the user aware of the presence of stored passwords by filling them, and nudge the user to delete them if they should not be filled.

(3) Credential Manager (CM) API cannot be currently enabled without the form-based password filling being also enabled.

My opinions:

Ad (1):
 * Our mid-term plans still include dropping the automatic filling for passwords as well (we call it "fill on account select - FOAS"). Once there, there will be no automatic filling left. While I would like an option to switch to that world immediately for interested users. But I can predict that the "interested users" is a population too small to justify adding a checkbox to the already long list of settings. So my vote here is to invest our efforts in FOAS instead.
 * We could re-consider if the name of the feature "autofill" still makes sense, and what exactly we want it to mean. I added this as an agenda item to our next autofill+passwords teams meeting.

Ad (2): On the assumption that we don't have a checkbox to disable 'automatic' filling as opposed to filling on user's selection of a suggestion, this reduces to asking whether we want to have a checkbox to disable any kind of filling of saved passwords. I maintain that allowing Chrome to have passwords stored silently and uselessly is not a good idea. My vote is to keep the current checkbox, only controlling the saving of passwords, and clarify the issue with the name "autofill", described above, instead.

Ad (3): I'm not sure about the benefits of enabling just CM API. In its current design, it makes getting at the password value harder for (potentially compromised) JavaScript in the pages, and fallback to form filling is one of ways around that. However, it is not the only way around that. And in fact, our team spent a lot of time recently discussing various security issues related to the CM API. The outcome will be ready for sharing later, but I can say as much as enabling CM API without enabling the form filling password manager would have no positive effect: most users would not care (=no effect), some users would care a little and enable that without knowing the other issues (=negative effect on security), and the security experts would realise this is still not enough (=no effect). There might be value in letting sites to disable form filling on their origins and sticking to CM API only. That's certainly something we keep considering, but again -- too early for sharing more.

Clarification on (3) as it sounds ambiguous. CM API can't be disabled. navigator.credentials.get() always works. navigator.credentials.store() and navigator.credentials.requireUserMediation() both guarded by the checkbox "Offer to save your web passwords". That means that if it's off then the user can't leave the auto sign-in loop but it's another bug.

ptoomey3@, it's unclear to me which audience you represent. If as a user you want to disable password autofill then you are right that it's impossible currently. If we decide to introduce this control then I'd rather tie it to the existing "Auto sign-in" checkbox instead of providing a new one.
However, if you are a site owner then the request isn't 100% clear. Do you have some usability defects when CM API and autofill work together or the motivation is only about security of the page?

> it's unclear to me which audience you represent.

A little bit of both I guess :-). 

> If as a user you want to disable password autofill then you are right that it's impossible currently. If we decide to introduce this control then I'd rather tie it to the existing "Auto sign-in" checkbox instead of providing a new one.

Yeah..it only surprised me since it seems to work unlike third-party password managers.  So, I figured it might be a bug and/or something in the future that could be added to match other password managers (I noticed since I always have my password managers configured to not autofill).

> However, if you are a site owner then the request isn't 100% clear. Do you have some usability defects when CM API and autofill work together or the motivation is only about security of the page?

Partly security and partly because it seemed inconsistent with one of the stated goals of the CM spec: https://www.w3.org/TR/credential-management/#fetch-integration:

> To prevent the risk that sensitive credential information will be exposed directly to a page’s JavaScript (see §6.1 Cross-origin Credential Leakage), we hide the credential information in non-web-exposed slots on the PasswordCredential object, and extract them during fetch() in ways that will remain opaque to anything other than the remote (same-origin) server.

So, it seemed inconsistent for the CM API to explicitly try to prevent credentials from being accessible in the DOM/via client-side JS AND for the password manager to do exactly that.

> And in fact, our team spent a lot of time recently discussing various security issues related to the CM API. The outcome will be ready for sharing later, but I can say as much as enabling CM API without enabling the form filling password manager would have no positive effect

Thanks..that is good information to have. Do you feel the issues are architectural/foundational, or could the security issues be resolved, and the CM API provide reasonable isolation of a plaintext credential from client-side code?

We are currently figuring out a way forward for both the CM API and the password manager to make them consistent.

For sure the CM API can provide reasonable isolation of a credential from JS. The questions we are investigating are "What is the price?" and "What is the value?"

Bumping this out of the unconfirmed queue.

I'll keep this open and assigned to me until I can get back with the following updates:

* Whether we could do anything about the confusing "auto" in the checkbox label in the settings.
* Whether we could consider letting the current "Auto sign-in" checkbox in chrome://settings/passwords control autofilling as well (thanks for the suggestion, Vasilii!).
* What are the public plans for making CM API consistent with form fill wrt. sharing passwords with JavaScript.

Happy to provide some updates:

* The feedback about the word "autofill" used in chrome://settings will be passed to relevant UI experts.

* With the team we decided not to bundle the feature to stop automatic (on load) filling with "Auto sign-in". The latter is very specific to Credential Manager API use, is synced across devices, and influences also some Android apps. The overall plan is to stop Chrome from automatic filling of passwords on load; once that happens, the meaning of the "Auto sign-in" checkbox would change again (being restricted back to CM API). This would be confusing.

* The public plans for making CM API consistent with form fill wrt. sharing passwords with JavaScript are at: https://github.com/w3c/webappsec-credential-management/issues/75

With that I'm going to close this issue as WontFix, because the team decided not to provide a setting to disable automatic filling until this becomes the default behaviour. We intend to make that change, but are currently busy with other priorities, and sadly cannot give an estimate on when it could be introduced.

Thanks for the detailed reply. I came across https://github.com/w3c/webappsec-credential-management/issues/75 earlier this week and thought to myself "Oh, hmm, I bet that chromium bug I opened up gets closed then." :-). And, so it does. 

Thanks again!