HTML: passwordrules attribute about standards-positions HOT 4 CLOSED

For the most part I agree with whatwg/html#3518 (comment) from Chromium but I also have some other concerns:

• While I find the use of <key>:<value>; more clear, it differs from syntax of CSP and feature policy. Would this be the first attribute that uses this syntax? Is it worth diverging from that prior art? @annevk had similar comments at whatwg/html#3518 (comment)
• The overlap with setCustomValidity and @pattern: whatwg/html#3518 (comment)
• This is likely to have low adoption and may encourage sites to add password requirements (as mentioned above too): whatwg/html#3518 (comment)

Without even taking into account ValidityState, our telemetry data shows that only 4% of generated passwords are edited after generation. That seems okay and I suspect only a small fraction of sites which rejected these generated passwords would even know to adopt this new attribute. (This telemetry mostly catches when sites do client-side validation before submission so the user knows to edit and may slightly under-count rejected passwords that are only caught on the server side.)

whatwg/html#3518 (comment) is the approach we were planning to take after supporting minlength/maxlength/pattern attributes (and possibly checking ValidityState.customError) so we don't have any plans to adopt this new passwordrules attribute. We will also use a list of recipes to override the generated password format for sites which don't use the constraint validation attributes but have unique requirements.

IMO this new attribute would be harmful if it encourages new password restrictions or if authors use it instead of minlength/maxlength/pattern/setCustomValidity, which are also useful outside of password generators.

from standards-positions.

I see some positives for sites with hard-to-change backends not thwarting password managers, but perhaps that's best catalogued in https://github.com/apple/password-manager-resources and not the frontend of those sites.

@linuxwolf are you interested in writing a PR for this, as nobody contested your comment and the one above?

from standards-positions.

"Restrictions on passwords beyond minimum length (and maybe a large maximum length) are all fundamentally bad" ... Do we really want to be adding a feature whose primary use-case is making it easier for already-broken sites to continue being broken?

Cementing this into a standard would somewhat agree with the status quo, I'm with Tab on this.

I had a proposal that merely permitted a site selecting the entropy which would restrict the length and also inform the password manager how long it should be safe to store. For example most sites aren't going to want a 50mb password but also a 50 character one might be overkill for a voucher token.

from standards-positions.

On the one hand, I think it would be very helpful to get hints for what a site wants for passwords. It helps password generators come up with something for the user faster.

However, I think this proposal is moving in the wrong direction. As @jonathanKingston points out, it cements – even encourages – bad practices, without promoting good practices (e.g., minimum length).

My personal opinion would be we lean toward harmful on this.

from standards-positions.