- From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Date: Fri, 17 Jun 2016 13:13:56 -0400
- To: <jcraig@apple.com>, "'ARIA Working Group'" <public-aria@w3.org>
- Cc: "'Michiel Bijl'" <michiel@agosto.nl>
- Message-ID: <013901d1c8bb$a28ffd00$e7aff700$@deque.com>
I can understand the need for an ARIA attribute that notifies assistive technologies that their text input will be masked. I frequently see credit card and SSN input fields being automatically masked by Javascript. The use of masking extends far beyond passwords, and notifying a users that an input field is masked does not imply that the fieldis a true password field with all the necessary security workarounds. With an aria-ismasked attribute we are providing important information to users without implying something that may or may not be true (i.e. that the information is secure). This attribute could be used on an editable div with the label of “password”. This attribute could be useful. The user agent/a.t. can offer the user the choice to override the masking if the user really needs to hear the feedback from what he/she is typing. I raised a similar point earlier, and I am personally very much not in favor of the password role, not without proper security revision. Given that other ARIA issues that are causing people problems on webpages today have been pushed out to ARIA 1.1 or 2.0 because they need more discussion, why do we have to force the password role through while there is very little need for it out in the wild? Thanks -Birkir From: jcraig@apple.com [mailto:jcraig@apple.com] Sent: Friday, June 17, 2016 12:06 PM To: ARIA Working Group <public-aria@w3.org> Cc: Michiel Bijl <michiel@agosto.nl> Subject: Re: Objection to password role This is a fairly damning amount of evidence. Michiel’s compilation makes it clear the working group process has ignored the advice of several members, including browser implementors, with regards to several serious concerns… not the least of which are: • user privacy • security vulnerabilities including XSS • incompatibility with assistive technology Why is this role still being considered? On Jun 17, 2016, at 3: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 <https://github.com/w3c/aria/issues/166#issuecomment-176638972> & Privacy IG (no reply) 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
Received on Friday, 17 June 2016 17:14:26 UTC