Re: Objection to password role

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