I don't see why you (or w3schools) would object to a warning being shown on that page. It's put forward as an example, it shouldn't be treated as real and something requiring security, so showing a generic warning confirming it's not secure is perfectly harmless and even expected

This is such a weird argument to have when incentivizing w3schools to use SSL would be a good thing. They can clearly afford the cost of acquiring, installing, and maintaining an SSL certificate. And as a website that teaches people about the web, they should be setting an example by using SSL. Alternatively, they should be setting an example by demonstrating that password prompts that aren't over SSL will cause warnings.

But even if it were legitimate for w3schools to not use SSL, security is about tradeoffs, and the tradeoff is that it's absolutely worth displaying a warning on one page that arguably doesn't need instead of not displaying it on millions of pages that definitely do.

It doesn't matter what the password is protecting on any particular site. Password reuse is common enough -- who knows what else the user is protecting with that password.

This is actually a good example. The password clearly isn't protecting anything. It's a tutorial on how to make a password field! Nobody is going to put a valuable password in there.

And now they'll have an extra reminder not to enter a real password in an example field. Seems good to me.

> 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.

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.

> 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?

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.

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.

The password form on that page _IS_ insecure and it's good that the user is given information about that. They can then make the decision about themselves about the lack of security and how it effects them and the page they are on.

Are you seriously suggesting that a password field in an online code editor on an HTML tutorial site is comparable to the situation we are discussing here?

The point is the result is the same - Chrome will flag that page is insecure.

Because it is insecure. Sure, that form doesn't actually do anything, but why not help and train visitors to expect security and know how to spot it?

w3schools is for web developers who are learning. Maybe they'll see that the page is marked Insecure and the lesson they'll get from it is that they need to secure their logins.

And the user will know they shouldn't type a password they want to keep secure into that field. Makes sense to me.