RE: Objection to password role

>>> For all we know, this role could be abused by malicious people in all kinds of ways.

Hammers, too. Role misuse is and was always possible. Same with HTML, by the way. This part of the argumentation don’t bring in anything new.

What is missing in this discussion is a comprehensive complete list of potential misuse and leaks for <input type=”password”>.

If this list is non-existing because the support and usage by authors is flawless across the Web and the Browsers, then it is a strong argument to use the host language entity.

If this list *can* be assembled and it is large enough than it offers probably enough stuff for a formal objection against HTML5.1 input password type.

As I said earlier, I think developers don’t mimic password fields because they are evil but because <input type=”password”> lacks features they need.

This is my everyday run-of the mill business seeing developers working around limitations of HTML5 + CSS pushing the boundaries and creating features HTML does not have. Violating basic accessibility and security rules, yes, but not evil-hearted, maybe careless, but willing to fix that if they have means for it.

Maybe one should scrutinize these cases and learn from it in a *timely* fashion extending <input type=”password”> host language features to avoid this?

Unless you don’t do this you have to live with hammer clones that have that other feature the HTML hammer does not have. There is a great lack of an “extensibility” concept for HTML widgets which is the major root case for all that brouhaha I read in epic threads like these for ages. ARIA fills that gap on a “meta” level, leaving complete control over this to browsers and authors. A thankless task, it seems sometimes to me.


-          Stefan


From: Marco Zehe [mailto:mzehe@mozilla.com]
Sent: Mittwoch, 22. Juni 2016 13:51
To: James Craig <jcraig@apple.com>
Cc: Richard Schwerdtfeger <richschwer@gmail.com>; Michiel Bijl <michiel@agosto.nl>; ARIA Working Group <public-aria@w3.org>; Ted O'Connor <eoconnor@apple.com>
Subject: Re: Objection to password role

Hi everyone,
here's the guy with the tiny tweet back from a Mozilla all-hands and finally enough time to properly respond.
Jonathan Kingston, a Mozillian working on security, has already raised several issues that I am not going to reiterate here. He voiced concerns way before the password role was discussed in a meeting, as can be seen in the Github issue Rich linked to. His blog post came after the meeting, but since this is still before a last-call state for ARIA 1.1, these concerns are just as valid.
And here's another point I'd like to explicitly raise, possibly repeating what someone else has stated in the past, but anyway:
2016-06-22 13:21 GMT+02:00 James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>:
Here's another example security problem: Browsers commonly save text typed into text fields, making it easier for users to reuse the same text later. This auto-completeable text is then available as an autocomplete in other fields, across sessions, often stored on disk.

For obvious reasons, native password fields do not work this way, but ARIA password fields would, because they wouldn't have the security support that is built into native password fields. ARIA password fields would be plain text fields (with no security features) masquerading as password fields. This seems likely to give the user a false impression of security. I'm certain I could come up with a few more problems, and I don't consider myself to be especially knowledgeable on the topic of security.
Another point is that not every AT has a screen curtain or screen obfuscation feature like VoiceOver on iOS (and Mac?) and TalkBack on Android do. Off-hand, I know of no single screen reader on Windows who has this. So there is no way for a Windows user in public to make sure their screen is masked so that nobody can sneak-peek over their shoulder while they're entering text.
If such a blind user on Windows, sitting with their laptop n an internet cafe or airport, are now enc ountering one of those wannabe password fields, they can not be sure that that field will indeed obfuscate what they type in. In a real password field, implemented natively by the browser, they can be very reasonably sure that that is the case. But with those wannabe password fields, they are completely at the mercy (or abuse) of the web author. Giving such web authors the means to pretend that this is a password field by just putting role="password" on it would put users at immense risk of publicly disclosing information they may never want to expose to the peeping tom. For all we know, this role could be abused by malicious people in all kinds of ways.
Our primary objective must always be to serve the user, as was also pointed out elsewhere already. Not browser vendors, not web authors or some other stakeholders, but users. And helping to keep users safe (or at least safer) from harm is in my opinion more important than anything else.
Also, another argument that was put forward was the desire of web authors to circumvent password managers. In my opinion, role="password" does nothing to that end. On the contrary, it even helps password managers to latch onto these fields and do their magic there, too. And frankly, I'd much rather have a user use a password manager to generate unique passwords for them than force them to use passwords they can easily remember. The latter would always lead to weak passwords that are prone to malicious attacks. And users with accessibility needs are no exception to that.
Oh and one last point: I've seen the feature of masking and unmasking password fields implemented with regular html:input elements. There's not much magic to that, so even that feature isn't helped with role="password".
I am all for pushing this role off ARIA 1.1 and revisiting that issue in the future, with proper use cases and security reviews that also take into account that there's enough measures in SVG to guarantee user security.
Marco