Thanks for the report.

Does saving work for a simple HTML form (like on https://rsolomakhin.github.io/autofill/) hosted on https://localhost?

Does Chrome report any certificate errors with https://localhost? (Check the left-hand corner of the URL bar).

Could you please open a second tab with chrome://password-manager-internals/ when you reproduce this issue and share its contents?

Also adding Vasilii, who has more insight into CM API.

I actually can't reproduce it locally because Chrome returns a certificate error.
Thus, in addition to Comment #3 I'm also curious how you deceived Chrome?

You're saying you get a certificate error from the promise correct? Yeah
that's not happening for me. I'm also not getting any error on
https://expired.badssl.com, the promise still succeeds but no error is
thrown and you aren't prompted for your credentials it just fails silently.
I reset all my chrome flags to the defaults and I still get the same
behavior regardless on the validity of the SSL cert.

Thank you for providing more feedback. Adding requester "vabr@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here is the output from the chrome://password-manager-internals/

```
------------------------------
CM API save a credential: origin=https://localhost/,
CredentialType=CredentialType::CREDENTIAL_TYPE_PASSWORD
------------------------------
SSL errors present: true
```

I was expecting it to work on https://localhost however it only works on
http://localhost

Here is the output from running on http://localhost

```
CM API save a credential: origin=http://localhost:8000/,
CredentialType=CredentialType::CREDENTIAL_TYPE_PASSWORD
------------------------------
SSL errors present: false
------------------------------
IsPasswordManagementEnabledForCurrentPage: true
------------------------------
Message: FormFetcherImpl::Fetch
------------------------------
FormFetcherImpl::state_: 1
------------------------------
Message: FormFetcherImpl::Fetch
------------------------------
FormFetcherImpl::state_: 0
------------------------------
Message: FormFetcherImpl::Fetch
------------------------------
FormFetcherImpl::state_: 1
------------------------------
Message: FormFetcherImpl::OnGetPasswordStoreResults
------------------------------
Number of results from the password store: 0
------------------------------
Message: PasswordFormManager::ProcessMatches
------------------------------
The new state of the UI: 1
```

So the expected behavior would be for it to work on https://localhost as it
does with http://localhost however even weirder is that some sort of error
should be thrown or the promise should be rejected if it is not able to
store the credentials, it shouldn't fail silently as it does now.

Thank you for your help it's really awesome to get such immediate feedback!

I meant that Chrome doesn't allow me to load the page because the certificate is invalid. Your flow is the same due to "SSL errors present: true". The API doesn't work because the certificate is invalid and it's expected. Am I missing something?

Yes but if you're testing on localhost you should still be able to test
with an invalid cert similar to how you are able to do so with other HTTPs
only APIs such as navigator.geolocation. I realize these work on
http://localhost but I just don't understand why it wouldn't behave the
same way as other HTTPs restricted APIs do on localhost.

Thank you for providing more feedback. Adding requester "vasilii@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mike, what does the spec say about this case?

We are using the same code as for password autofill. I'm hesitant to change it. Can developers somehow test with a "valid" local certificate?

> Mike, what does the spec say about this case?

The secure context spec says that `https://localhost` is a secure context assuming that it's "HTTPS state" is "modern". Fetch leaves a good deal of wiggle room for browsers to decide what exactly that means (see the note at https://fetch.spec.whatwg.org/#concept-https-state-value).

I think I agree with the reporter that it's strange for us to accept the user's decision to trust a given context for the purposes of some subset of restricted APIs (geolocation, getUserMedia, etc), and not for others (autofill, credential management).

> We are using the same code as for password autofill. I'm hesitant to
> change it.

+battre@, who I think has a doc on this somewhere?

If https://localhost is secure then Chrome shouldn't pop up the red interstitial page with "Privacy violated" message. currently one can't get to the page without dismissing the warning. If the security team changes it then the API would work fine.

> If https://localhost is secure then Chrome shouldn't pop up the red interstitial page with "Privacy violated" message. currently one can't get to the page without dismissing the warning. If the security team changes it then the API would work fine.

`https://localhost` is Totally Secure(tm) if the user installs the root cert used to sign the `localhost` cert into their OS's trust store. In that case, the user wouldn't receive an interstitial, and wouldn't need to click through anything, because the locally-installed root would confer trust on the origin.

In most cases, though, the web-facing notion of a "secure context" doesn't particularly care whether trust is established implicitly by chaining up to a trusted root cert, or explicitly by the user clicking through an interstitial. We'd consider the origin Secure Enough(tm) in either case to allow geolocation access, for instance.

Autofill and the password manager have an additional check on top of the "Was this delivered via a TLS connection the user chose in some way to trust" that web-facing features generally use, which additionally enforces the constraint that the TLS connection can't have had an interstitial which the user bypassed. It's not clear to me that we have a defensible threat model there. That said, I also haven't thought a ton about it, so. :)

Ok, couple of statements I believe in
- If a developer makes the localhost certificate trusted then the API works fine. Thus, they are not blocked with testing their sites today.
- CM API and password autofill should have the same security properties. In particular, there should be no way that CM API works on X but autofill doesn't.
- There is a project to allow password saving/filing on self-signed origins. When it's done we can tweak the CM API to work the same way on those sites.

Thus, I think we shouldn't patch our code to work in a special way just on https://localhost. Please correct me if I missed something.

Dominic, do you agree?

I didn't really expect this much discussion, *thank you all for looking
into this*. I'll just configure my machine to allow the certificate as a
work around. I think the only issue is the inconsistency between the APIs
which isn't necessarily a problem, it was just difficult to find out why it
was failing because there was no error and no differentiation between what
is considered secure context when testing locally within any of the
documentation I read.

And just for reference, the bug tracking the general changes to working on pages with broken HTTPS is issue 431618.

All right. Let's fix this bug once the password manager supports the self-signed certificates.

vabr going hobby only -> reducing involvement.
Please contact me directly in urgent matters.