Re: Objection to password role

Hi James,

I have had, and continue to have, many concerns around this role value. I
too have (had?) concerns over the process piece here (it was extremely
weak), and those concerns were made public, and discussed in private with
the WG staff contact. We still need a Formal (as opposed to informal)
security review, and while we are discussing process, the CfC that was
accepted noted:

“This CfC received only messages of support, and is therefore agreed as a
decision of the ARIA Working Group to include the password role in the ARIA
1.1 editor’s draft, <highlight>subject to security and AT feedback
</highlight>, and to move role=“text” to ARIA 2.0.”

– and again, it is unclear whether we’ve had sufficient security feedback.
I will also return to Joanie’s open Action Item to attempt to solicit
feedback from Apple, and I don’t recall getting any specific yay or nay
from NVDA, so the subjective condition of the CfC including AT feedback –
as published by Rich on April 21st (
https://lists.w3.org/Archives/Public/public-aria-admin/2016Apr/0030.html) -
has not yet been met.

As noted, there are also related Action Items to this that remain open
still today:


   - ACTION-2061: Speak with apple about voiceover rendering, rendered text
   for passwords
   ​
   (https://www.w3.org/WAI/ARIA/track/actions/2061)

   - A
   CTION-2062: Work with apa to address password roles/elements/credential
   management in a secure environment for tpac
   ​
   (https://www.w3.org/WAI/ARIA/track/actions/2062)


I was *this close* to filing a Formal Objection on this w.r.t. ARIA 1.1
except for the one use-case presented that has no alternative solution
today - SVG.  I personally think that's a lousy state of affairs, but
because we do not have a native password input concept inside of SVG today,
and yet a need for such exists (*), I see this as an attempt to ensure that
the lousy workaround being used in places like SVG can be made more
accessible, and that's kind of hard to argue against. As an absolute
minimum, I stood down on pursuing further objections when we managed to get
the following Warning into the draft spec. I don't think the pull has
happened yet, but the warning states:

 <p class="warning">
                    The <code>password</code> <a>role</a> does not convey
or apply any of the security or privacy considerations found in native
password fields. Authors are responsible for making sure that custom
password fields have robust security and privacy protection, as befits
their use.
</p>

(* determination of need: we have heard there is a need, yet repeated
requests for examples in the wild today of this need have been met with
silence. I for one would love to see an example of this today, but one has
not been brought forward)

At the time, I didn't seem to have a lot of support for going any further
than that - Leonie and I had concerns, but I wasn't getting a lot of
backing beyond that. I'd still support deferring this to ARIA 2.0 if there
is enough support within the Working Group for that, or if another W3C
member org raised a FO, but frankly I wasn't going to continue to bang my
head on this wall without broader community support.

There is a special functionality that is being demanded of the
screenreaders here, and frankly there is some greater functionality with
any password input that also has a dependency on the browsers, but if time
(and repeated reminders) has taught us anything, it is that the browsers
themselves don't want to do much with ARIA expect pass it along to the
Accessibility APIs and move on. If an ARIA role of 'password' also impacted
the browsers in a way that any editable container with that role also
assumed or invoked the same security considerations that <input
type="password"> provided, I think we'd be having a very different
discussion. But that would require the browsers to back off their prior
stance of not having ARIA impact the UI or other browser functions, a
position I'd love to see, but don't expect to see any time soon.

There is a high demand to proceed with the publishing of ARIA 1.1, and yet
this particular role attribute remains troubling, even with the proposed
warning language. I would support the removal of this role value in the 1.1
timeframe, but at this time I will only support that request if it comes
from elsewhere in the Working Group - I have already raised my concerns and
they were dismissed by the WG. I did manage to get the agreement for the
Warning, and that was better than nothing, so I accepted that as a weak but
still helpful advancement.

JF

On Fri, Jun 17, 2016 at 11:05 AM, James Craig <jcraig@apple.com> wrote:

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


-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion