Re: Objection to password role

Apart from the password role discussion, there was a side proposal,
the need of having an aria-masked attribute for inputs that mask char input on the fly.

I'd like to mention that there are also "input masks" (done by JS) that present a formatter string inside an input and do not mask chars on the fly but expect a certain char type at a given position in the mask, especially for non-standard formatting. Think of the excel cell value schemes and you have the idea. We must not confuse this with aria-masked, instead we would need annother attribute, such as aria-formatted or likewise to handle these cases in aria 2.0. This concept is NOT supported by HTML although I've seen developer attempts to bypass this limitation for ages.

- Stefan

Sent from my iPad

On 18.06.2016, at 21:24, Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>> wrote:

Michiel,

All concerns that have been raised have been addressed.

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.
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.
3. We agreed to have 2 implementations of 2 as a condition for exiting CR.
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
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.
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 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.

Best,

Rich

On Fri, Jun 17, 2016 at 5:10 AM, Michiel Bijl <michiel@agosto.nl<mailto:michiel@agosto.nl>> wrote:
All,

A lot has been said about the password role. Security problems, lack of good use cases, and difficulties for users. Despite all that, it seems it will still get into the final specification. I would like to quote the 'Priority of Constituencies<https://www.w3.org/TR/html-design-principles/#priority-of-constituencies>' (thank you Jonathan Kingston for reminding me<https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/>):

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

How is adding a role-where one of the use cases is preventing the use of password managers-helping the users? How does that adhere to the priority of constituencies?

To give some background to this e-mail, I've looked up some discussions on the list:


  *   James Craig opposing this on potential security implications<https://lists.w3.org/Archives/Public/public-aria/2016Jan/0064.html>
  *   L?onie Watson expressing concerns about character obfuscation<https://lists.w3.org/Archives/Public/public-aria/2016Jan/0065.html>
  *   Birkir Gunnarsson stating we are reinventing the wheel<https://lists.w3.org/Archives/Public/public-aria/2016Jan/0066.html> (and suggesting we might be better of with an aria-secure attribute)
  *   Brad Hill on security risks and website identify verification<https://lists.w3.org/Archives/Public/public-aria/2016May/0009.html>
  *   L?onie Watson expressing concerns about AT's announcing "custom password"<https://lists.w3.org/Archives/Public/public-aria/2016May/0001.html>
  *   John Foliot expressing concerns in general about the password role<https://lists.w3.org/Archives/Public/public-aria/2016May/0004.html>
  *   Me asking for an update on contact with the Security & Privacy IG (no reply)<https://github.com/w3c/aria/issues/166#issuecomment-176638972>

Some more background links:


  *   Original post to list by Joanie<https://lists.w3.org/Archives/Public/public-aria/2016Jan/0053.html>
  *   Issue on W3C tracker<http://www.w3.org/WAI/ARIA/track/issues/1005>
  *   Security check by Microsoft<http://www.w3.org/WAI/ARIA/track/actions/2020> (W3C tracker issue)
  *   Jonathan Kingston's excellent piece on the password role<https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/>
  *   Marco Zehe agreeing with Jonathan's article on Twitter<https://twitter.com/MarcoInEnglish/status/743680877444497408>


I've reread large parts of the threads, and don't see any good reason to implement this. There don't seem to be a lot of people in favour of this role. There are however a lot of people raising concerns. There hasn't been a formal review by any of the security working groups as far as I can tell.

So why is this role being pushed so hard despite all the concerns raised?

-Michiel




--
Rich Schwerdtfeger