Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections...

There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.

I haven't heard of this bug, but regarding the decision to mark all HTTP as insecure:

Remember, HTTPS isn't just for security, but also privacy. And even if your site is such that there is no privacy advantage in hiding the exact URL you visited (as opposed to the hostname, which unfortunately must leak for now), even if there are no cookies sent to your site, or to any iframes it uses, which can be used for identification or profiling…

Even then, there are the benefits that only accrue if a user's entire browsing session is HTTP-free, including hiding the user agent from a network attacker and preventing injection of everything from tracking cookies to DDOS scripts (China's Great Cannon) to zero-day attacks.

> Remember, HTTPS isn't just for security, but also privacy.

And the third thing: authenticity.

No-one has modified the page, for example to insert or change advertisements

I don't really know what your point is.

This will mark pages as insecure that have a '<input type="password">' field on your page. If you don't have that, you are fine.

I don't know of any reasons to have a password field if it's not actually sensitive information that's being entered.

...for now. Marking all non-secured HTTP as insecure (duh) is in the pipeline - it seems.

This is actually a Good Thing - with HTTPS-friendly CDN and/or Letsencrypt, rolling out sites that are secure-by-default is now easier and cheaper than ever before.

Well...HTTP is insecure. That's what S in HTTPS stands for.

Then that's a bug you should report, and let the Chrome team fix it.