Re: Objection to password role

> On Jun 22, 2016, at 6:51 AM, Marco Zehe <mzehe@mozilla.com> wrote:
> 
> 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.

Marco, 

First, thank you for responding on your thoughts directly to the list vs. a tweet. I read Jonathan Kingston’s blog and he did not post it to the list. Joanie mentioned it in a link on June 17:
https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/ <https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/>

Publishing something in a blog is not the same as submitting this to the list. 

When I read this post I read it as someone who simply does not like ARIA at all and does not want us placing features in ARIA that exist in HTML. I will quote Jonathan from the blog: "ARIA <https://www.w3.org/TR/wai-aria-1.1/> is a hack on real accessibility"

I will tell you that the web components people have asked for the opposite. They have asked for more HTML semantics in ARIA. 

I would like to address his next point: "So initially security people <https://lists.w3.org/Archives/Public/public-aria/2016May/0009.html> did not really raise issue with role="password" as it doesn’t directly create security risks, however it is my view that it permits bad web authorship and promotes hurting users experience on the web.”

This issue has been raised (nothing new here) by the web security people but whether we put the role in or not people are creating custom password roles as the functionality in HTML does not meet their needs. This is also why people create custom widget libraries. So, what this is saying is that to help enforce security people must sacrifice accessibility. I have a big issue with that, especially given that the presence or lack of the password role has not stopped people from doing creating custom passwords.


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

So, one point about this. These are NOT ARIA password fields. They are author-defined password fields that would add a password role. 

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

So, how is a password role going to have any effect on that. This is the situation we have today. I am confused. 

> 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.
> 
Marco, this is where it would have been helpful to have Mozilla in the discussions as you missed the following:

1. Screen readers are doing keyboard echo on password fields that are custom. They are not obvuscating, verbally, the text. They do this for performance reasons. So, without a password role to indicate that this is a password field they are not speaking the “rendered” text. Also, if the password role is applied we would ask ATVs to speak only the rendered text and not say star star star. 
2. We also discussed exposing this as a custom password field versus a password field. IOW if we were to apply the password role the user would know this was a custom password field. We could address that with ATs. This would be a definitive statement as to whether it is custom. Without a password role there is no guarantee that you will know. 
3.  Brad Hill from the security group stated that the real issue was that we needed ATs to speak the security icon in browsers. 

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

My previous 3 bullets would do this. Without the password role there is nothing that will server the user on a custom password field. Telling authors to go use the HTML password input has already come and passed at this point. 

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

See custom password above. Also, John Foliot has put some excellent warning text in the password role for authors to help address this. 
> 
> 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”.

Actually, that is not correct. If the screen reader were to speak the rendered text vs. they keyboard echo you would know that what you were typing was in the clear. I agree that does not help with non-password input fields but that was not the use case we were addressing. 

> 

> 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.
> 
Please read the above. I think there is new information you have not been exposed to. 

Best,
Rich


> Marco
>