Comments (4)
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.
Related Issues (20)
- `autocomplete=device-eid` and `=device-imei` HOT 3
- Digital Credentials HOT 4
- getHTML() and the serializable concept HOT 1
- CSS `@starting-style` HOT 1
- Snap Events HOT 4
- Constructors for RTC Encoded Frames with metadata HOT 1
- Importmap integrity HOT 2
- Consider adding WebKit standards-position URL to the issue template
- document.caretPositionFromPoint API in shadow DOM scenario HOT 1
- CSS Nesting: @nest HOT 5
- Reduce Accept-Language
- Web Translation API HOT 1
- AudioContext.onerror HOT 3
- Allow converting VideoFrame to RGB pixel formats by calling VideoFrame.copyTo() HOT 1
- Still on SerialPort API HOT 3
- The ChapterInformation interface HOT 3
- HTML Fullscreen Without A Gesture
- ShadowRealm API HOT 3
- Dialog light dismiss HOT 2
- WebGPU: ServiceWorker and SharedWorker support HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-positions.