Re: Objection to password role

> On Jun 21, 2016, at 3:53 AM, Michiel Bijl <michiel@agosto.nl> wrote:
> 
> 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.
> 

People are doing this already. One example is what if you want the user to see the password they are typing based on their request? You are not going to do that with the HTML password unless you write it elsewhere. Our argument is that people are doing this already. CSS does things that encourages people to break accessibility too. That does not stop them from putting it out the door. JavaScript encouraged people to create custom controls that were not accessible. We invented ARIA. We did not say Don’t do that. Also, it is much more work to do something other than use an HTML password so why would they do it unless they needed to provide additional functionality? I challenge you to tell developers not to use JavaScript because it encourages them to create things that are inaccessible. 

I would also argue that putting role=“password” on an element does nothing advance the work of someone trying to create a custom password. So, it encourages nothing. In fact, John Foliot placed some excellent warning text about this to address that point which was passed as a decision. 

The WSIG did not want to have a formal meeting or review but instead chose to respond on list. Here is the email from Brad Hill regarding the security issue that needed to be addressed by AT vendors regardless of whether a password role was applied:

https://lists.w3.org/Archives/Public/public-aria/2016May/0009.html <https://lists.w3.org/Archives/Public/public-aria/2016May/0009.html>

I would also point out that you took the minutes at the meeting where the password role was accepted. Although you suggested moving it to ARIA 2.0 you did not object on the call:
https://www.w3.org/2016/05/26-aria-minutes.html

This raises an issue for me as you are actively forcing a rehashing of this issue even though you attended the meeting and did not object at the time. That is not acceptable or fair to your colleagues in the working group. 

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

I gave you one reason above. I need to dig up the minutes of the meeting where James Nurthen went through use cases for it. One of the problems is that we discuss these issues at meetings and Charles does not attend them. Not everyone in our group can camp on email all day long responding to things. We reserve time at meetings to discuss these things. James Nurthen discussed the business cases for this at a prior ARIA call. I have not found that in the minutes which is frustrating. What I will do is ask James to get us links to sites that write the custom password roles. This may take some time so I am willing to recommend we put password role in as “at risk” as we go to CR. I did however give you one use case. 


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

That is beyond the scope of ARIA. See the link above. The Web Security IG decided to respond on list to questions versus sending a formal response. 

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

That is less of an issue right now as there is no vehicle to provide a caret location for any custom SVG input field - that would need to be addressed in ARIA 2.0. I would say though that even though you can use HTML in SVG the reason you use SVG is so that you can zoom in and out and it will look roughly the same. So, placing HTML text in the middle of that would look ugly. 

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

I am working to get JAWS support. We do have Linux support. I have not heard from Apple or Microsoft yet.  The purpose of CR is implementability. It is not to get support in every major implementation that holds up nobody on CR. The problem I have is that the people who are asking for the world are not willing to go out and get the world on board. I think putting the feature at Risk is important. If we don’t get 2 implementations in browsers that and ATs that would stop it going into the final recommendation. 

>> 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.
> 
Nothing in ARIA impacts the browser UI. So, we agree completely. It does tell authors they get nothing for free so use the standard HTML password input control type. 


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

****NO.**** ARIA does not impact the browser UI. The browser vendors have stated this. ARIA is simply there to communicate what the the objects are, their states and properties, and when those states and properties change to ATs. This was a HUGE source of contention with browser vendors. 

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


What I am seeing is that people are wanting to rehash what was already discussed and agreed on in meetings. What I am not seeing is James Nurthen’s comments in the minutes as to why custom passwords are created. I will ask for that again. I disagree that we did not get a security review. I am also concerned that if we don’t have the password role we will have a security issue regarding ATVs not speaking rendered text for custom password widgets. 

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

When you have a custom password and no password role AT vendors are echoing the keyboard key typed versus speaking what is actually rendered. This is for performance reasons it means people in the vicinity can hear what you are typing. Speaking the rendered text slows the response down as you have to go back and communicate with either a virtual buffer or the actual control what is being rendered. The value is not what is rendered either. By having a “password” role you can speak the rendered text in these situations. If the text is supposed to be obvuscated and you hear the actual password you typed you know you have a problem. By limiting this to password role you will ensure the best performance possible for other input text types while enabling the user to know when they are exposed by what is rendered. This has been discussed on calls and if this still is not clear come to Thursday’s call and ask us to explain it better. We will do that. Without the password role ATs would need to change to read the rendered text for all text input types which is MUCH slower. 


VERY IMPORTANT. If you have these issues you need to make sure they are FULLY vetted on calls - especially those you attend. When the group resolves on issues and then you come back and object you are rehashing things and forcing people to take their days going back through all the minutes and email discussions to show you what was covered. 

> —Michiel