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>:

> 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