Re: Objection to password role

Rich,

> 1. A security review. This was done through the security interest group and Microsoft's browser team. The only issue that was stated was that was a concern by the security team interest group was that assistive technologies need to make the user aware when the security lock is not on. We are taking that up with AT vendors even though this has nothing to do with the password role. This would be an issue with or without a password role. Microsoft so no issues.

Has there been a formal review by the Web Security Interest Group? And if so, where can I find that? Is it this one: Security Evaluation Request (role=password) <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0003.html>? Some snippets from that thread on the WSIG:

Gerv said in their first reply <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0008.html>:

> Well, it encourages people to use non-password fields for passwords, which is arguably a security problem because if people's password managers don't save the passwords, they are more likely to use bad (simple, short) passwords.

Tanvi said <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0016.html>:

> If we create role="password", browsers and password managers will adapt to treating role="password" the same way as they treat type="password".  Then the same websites that purposely avoid type="password" will start avoiding role="password”.

Rich, you said the following <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0011.html> in that thread:

> Companies that must do this for business reasons need a way to make it accessible.

Chaals asked for use cases <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0018.html>, but didn’t get a reply:

> Hence my earlier question about the use cases. What are the needs that people think justify not using a "real" password field?


Virginie said the WSIG would soon have a call where issues could be discussed <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0024.html>. John Foliot asked <https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0025.html> if browsers would apply the same security to role=password as they would to type=password. There were no further replies or questions asked.

I’m not quite sure how one can conclude that there are no issues based on these replies. As far as I can tell, there has been no definitive answer from the Web Security IG.

> 2. AT vendors not rendering the actual rendered text with non-HTML password input types where the author is rendering a custom password. This problem is NOT limited to the password role. What can be done is have the actual rendered text spoken vs. asterisks. What is happening now is if a custom password is provide without a password role the actual text is spoken by ATs for all users to hear even if the text is obvuscated. It is expensive, in terms of performance, to have to read the text rendered. With the introduction of the password role we can make the exception and we have a second AT vendor in the process of making that exception. This creates better security than we currently have on the web. This goes above and beyond the requests of the security experts. 

Are there any use cases for custom password fields that benefit the user? Multiple people have asked for use cases for this role, and I haven’t seen any replies to those questions. 

Someone did say there is no way to make a password field in SVG. Again, I would like to hear about some use cases here. That said, someone on the Edge team told me last week that you can now use HTML inside of SVG. They too are curious to understand the use cases.

> 3. We agreed to have 2 implementations of 2 as a condition for exiting CR.

This doesn’t make any sense if those two implementations account for a marginal proportion of the market. Furthermore, both Apple and NVAccess have expressed concerns about the implementation of this role. That marginal market share of those pieces of software conflicts with the ‘Priority of Constituencies’; the majority of users will be left with a screen reader that does not support this role.

> 4. The inclusion of warning text on the use of the password role for authors regarding it not providing any additional security features. John Foliot has provided that text and it is being incorporated

It won’t add security features. It might convince some developers to do the right thing though.

> 5. Making ARIA force the browser to obvuscate any text of the password role. It has been the unwavering policy of this group to not mandate that browser change how they render their UI. This has been an emphasis of browser vendors since day one. It has been a line in the stand.

I don’t understand this paragraph. If indeed a password role is introduced, browser should obfuscate text, no? They should also prevent you from copying the text inside it, like a real password field.

> 6. A sixth suggestion was provided regarding readonly password field that I don't fully understand and which I believe will change in ARIA 2.0 due to the addition of an accessibility API. I don't object to this text staying in other than I am confident it will need to be removed later. For example, if you want to create a password field in SVG you would need to convey the caret position and that it is a password field. SVG has NO "editable" elements. A similar issue involves Google Docs where they create their own caret. 
> 
> So, although you are welcome to object, ALL issues have been addressed

The replies to this thread tell a different story.

> and we are providing greater security with the password role with minimal impact to AT vendors. This summarizes the entirety of the issues,  and the solutions to addressing those issues.
> 
> I hope this summary helps you to understand what has transpired and why we have a better solution for custom password fields that before.

No, I do not see this as a better solution; I cannot see this as a better solution without any real use cases. That said, my previous question hasn’t been answered: why is this role being pushed so hard despite all the concerns raised?

—Michiel