[wfunction]

> who knows what else the user is protecting with that password

How does it even matter when the password field is never even read? There are better alternatives. Chrome could just give a security error when the password is actually accessed. Or alternatively it could prevent the page from storing any data locally or sending any data to any server if the password field is non-empty. Just because a password field exists that doesn't mean the page is insecure.

[andrewstuart2]

If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality.

If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. Might as well swap it for an input and, voila, your users won't have any warnings.

[wfunction]

> If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway.

You don't think it was adding anything in the example page I just linked you to?

[andrewstuart2]

Only a false sense of security.

Since the page is loaded as plain text, it can also be altered by anyone with network access between the server and the user. Javascript can be very trivially injected that simply sends each keydown event to the server, giving away the user's "hidden" password.

So even if the code you wrote doesn't ever send the password input to the server, that doesn't mean code hasn't been injected by some third party by the time it gets to your customer/user.

[ledriveby]

Can't do that when JS can access the field contents asynchronously via the DOM. Blocking JS execution for a user prompt wouldn't fly, either.