Chrome 56 will mark HTTP pages with password fields as non-secure

Re:Chrome 56 will mark HTTP pages with password fields as no... by Symbiote on Sunday January 22, 2017 @05:44PM (#13458080)

I think the point is more like an HR administrator who opens a web page, containing an employee's details. They need to update the employee's home phone number, but their password manager dumps the HR administrator's password into the "Set new password" field, which is therefore overwritten.

[ Parent | on HN ]

Re:Chrome 56 will mark HTTP pages with password fields as no... by icebraining on Sunday January 22, 2017 @07:46PM (#13458754)

So don't put the "set new password" field right in the employee's details page, use an extra page or popup for that.

[ Parent | on HN ]

Re:Chrome 56 will mark HTTP pages with password fields as no... by mappu on Sunday January 22, 2017 @11:26PM (#13459753)

Our application is still maintained, so we can find workarounds or restructure the form to use an extra popup (to the detriment of usability). But i'm sure many applications won't be updated, and as a result of this change, data will be silently corrupted when they are used. The browser has knowingly broken compatibility with the web application.

This is a Torvalds "don't break userspace" moment.

[ Parent | on HN ]

Re:Chrome 56 will mark HTTP pages with password fields as no... by icebraining on Monday January 23, 2017 @02:33AM (#13460521)

Fair enough, that's a valid concern. But it wouldn't be solved by allowing pages to opt-out of autofill, since they'd have to be updated to use those as well.

[ Parent | on HN ]