HTML: passwordrules attribute

[annevk]

In whatwg/html#3518 Apple engineers propose a new attribute for <input type=password> that'll assist password generators doing the right thing.

I'm personally enthusiastic about the idea.

(There's many small incremental features like this added to WHATWG standards. It's not quite clear to me if we want an issue for each of them, but we probably do want a Mozilla position on each of them, so... Filing this one as a test.)

[jonathanKingston]

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

[linuxwolf]

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.

[annevk]

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?

[mnoorenberghe]

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 Proposal: HTML passwordrules attribute whatwg/html#3518 (comment)
• The overlap with setCustomValidity and @pattern: Proposal: HTML passwordrules attribute whatwg/html#3518 (comment)
• This is likely to have low adoption and may encourage sites to add password requirements (as mentioned above too): Proposal: HTML passwordrules attribute 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.