Does this also affect:
* blob:// URLs
* file:// URLs
* about:blank

It repros for about:blank (see test at end of https://bayden.com/test/data.htm)

I have every reason to believe it repros for blob://.

file:// is less interesting because sites can't navigate users there.

Notably, this isn't much of a mitigation for combating phishing via data: Urls. A bad guy who wants to phish via data will could use a regular INPUT TYPE=TEXT with a dot font so it looks like a password field. (The value of the HTTPBad "Not Secure" work is in nudging legit sites to start using HTTPS properly; I don't think any legit sites are using login fields on data protocols).

Confirmed repro for blob too.   (see test at end of https://bayden.com/test/data.htm)

I think #2 meant filesystem: instead of file:. I don't see a reason filesystem: is affected too.

> I don't see a reason filesystem: is affected too.

must be "is *not* affected".

The bug is that GetSecurityLevelForRequest() checks for url.IsStandard() before returning a "Not Secure" security level. url.IsStandard() uses kStandardURLSchemes which doesn't include "data" or "blob" schemes.

Oddly, kStandardURLSchemes does include "filesystem" scheme, but the verbose state is still not shown on filesystem URLs.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/39f049e94f28f0c26dba4aae5fe7d2818d4c570d

commit 39f049e94f28f0c26dba4aae5fe7d2818d4c570d
Author: meacer <meacer@chromium.org>
Date: Wed Feb 08 20:09:05 2017

Show form not secure warnings for blob and filesystem URLs.

These URLs do not define a secure context by themselves. They can be
created by HTTP URLs in which case they should be treated same as HTTP
URLs. Additionally, there is a spoofing risk associated with these URLs,
so mark them as "not secure".

Note that this CL excludes data: URLs. data URLs are being marked as
not secure in https://crrev.com/2648353005, regardless of whether they
display a password/credit card field or not.

BUG= 680810 

Review-Url: https://codereview.chromium.org/2643083003
Cr-Commit-Position: refs/heads/master@{#449072}

[modify] https://crrev.com/39f049e94f28f0c26dba4aae5fe7d2818d4c570d/chrome/browser/ssl/security_state_tab_helper_browser_tests.cc
[modify] https://crrev.com/39f049e94f28f0c26dba4aae5fe7d2818d4c570d/components/security_state/core/security_state.cc
[modify] https://crrev.com/39f049e94f28f0c26dba4aae5fe7d2818d4c570d/components/security_state/core/security_state_unittest.cc

Reopening, about:blank is still not fixed.

It looks like fixing about:blank is more complicated. Both blink and browser side use kSecureSchemes to determine if the scheme is secure before doing the password & credit card check, and about:blank is listed as a secure scheme (https://cs.chromium.org/chromium/src/url/url_util.cc?type=cs&q=kSecureSchemes&l=52)

I filed bug 696810 to change that.

This is fixed for data and filesystem. about:blank is tracked at bug 696810.