Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group Resolutions

Hi Rich,

>
​
 Do you mean obscuring text when author claims it is a custom password
field?

Yes, that would be the ideal solution as far as I can see - that any time a
widget claims to be a password widget, that it operates exactly like
previous password inputs have behaved over the past 20+ years. My question
is, have we even bothered to ask the browser vendors if this is possible?
Like you, I don't hold out great hope for that, but it *IS* worth the time
to ask. Getting 4 out of 5 browser vendors to agree seems far easier than
getting 16 out of 20 screen reader vendors to agree, right? (Using the 80%
rule as a starting point)

>
​
What I am concerned about and not a single person complaining has failed to
address is text fields which are password fields but which the ATs always
echo the characters typed which creates a security hole.

And again, it comes down to this: a text entry field that claims to be a
password entry field in name alone, but without *ALL* the expected
behaviour that password inputs have traditionally delivered to date, really
isn't a password input, is it? (Or in other words, I can paint a racing
stripe on my car and call it a Formula 1 race car, but both you and I will
know that it's really still just a Honda Civic, no matter what I call it.)

Creating an ARIA role that purportes to identify password inputs to
non-sighted users who cannot visually verify that fact, an ARIA role
without the actual ability to enforce expected outcomes, is in my mind a
recipe for disaster and a far more serious problem that faux password
inputs that echo back characters when the user types them in - that appears
to be a problem the end user can deal with already, as Matt KIng has
previously noted: "Note that without the password role, *the user is in
control*. All screen readers have a key for turning off key echo. So, no
password role is the safer course if we can not resolve the conflict." -
https://lists.w3.org/Archives/Public/public-aria-admin/2016Mar/0035.html

No. I and others have heard this concern. But as Leonie has noted, you seem
to be trading one security issue for another here: "It changes the security
risk, it doesn't narrow it down. If anything the uncertainty factor makes
it a much more serious problem." -
https://lists.w3.org/Archives/Public/public-aria-admin/2016Apr/0014.html.

Never-the-less, the proposal being brought forward is that we attempt to
get changes into 2, 3, maybe 4 Screen Readers to address this problem by
using Joanie's suggestion, to not worry about any other screen reader at
this time so that we can ship ARIA 1.1, and then, what? Buyer Beware? It
works with Orca and Narrator, but not Voiceover or Talkback, but hey, close
enough to ship ARIA 1.1? Surely Rich this isn't what we are proposing is
it? I see that as keeping ARIA 1.1 on track, but how does it close the
security hole you yourself have expressed concern over?

I don't think anyone who has participated on this thread doesn't understand
the concern you are attempting to resolve. I have already stated that I
think Joanie's proposal has merit, but by shifting a "security"
concern/solution from the half-dozen or so browsers to the much longer list
of Assistive Technology solutions in the marketplace, you've (we've?) also
added multiple potential failure points across each AT. Without broad
commitment from those AT Vendors, it's just another good idea. Multiple
times it has also been suggested that we approach the Security folk at the
W3C (Leonie, Chaals, Wendy, myself have all made this suggestion) to get
their feedback and opinions, yet I've not seen any action or attempt to do
that (and yes, if you want to assign that action item to me I'll write the
email this week and try and kick things off there).

The bottom line here Rich is that we all see the potential security
problems from all of the different vantage points. But a hasty
lick-and-a-promise "sorta" solution is not really a solution at all. I
appreciate the desire to get ARIA 1.1 out the door in a timely fashion, but
I also reject doing so by implementing half-baked security fixes that only
a few screen readers *MAY* support. If it's worth fixing, it's also worth
getting right. I fear that the current proposed plan falls significantly
short of that at this time.

JF



On Sat, Apr 2, 2016 at 1:31 PM, Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

>
> Rich Schwerdtfeger
>
>
>
>
> On Apr 2, 2016, at 10:55 AM, John Foliot <john.foliot@deque.com> wrote:
>
> > I don’t know for sure yet but if VoiceOver is using the HTML password
> input type to decide if the characters are masked and echo a sound then
> this is a problem for custom password fields. So, let’s say you don’t put a
> role=“password” on the field VoiceOver will echo the characters even if
> they were not obscured. If you do put a role=“password” and it speaks the
> semantic sounds vs. the characters and the author has not obscured the text
> then the user does not know that the text he is typing is in the clear.
>
> Hi Rich,
>
> Therein lies the root of the problem.
>
> Creating a newly abstracted role that suggests or implies any form of
> Privacy or Security has to have a mechanism whereby the end user can trust
> what their system is telling them is in fact true. I recognize getting
> browser vendors on board here may be problematic, perhaps even not
> possible, but - have we even asked? Getting 5 or 6 browsers on-board may
> ultimately be easier (effort wise) than chasing after 20 or more different
> screen reader vendors (The AFB lists 18 possible tools on their website at:
> http://www.afb.org/ProdBrowseCatResults.asp?CatID=49)
>
> I am not sure what you are asking for the browser to get board with. Do
> you mean mapping the role?
> ​​
> Do you mean obscuring text when author claims it is a custom password
> field?
>
>
> > I have a to-do to reach out to other vendors - previous post. Dolphin
> and GW Micro were on my list to reach out to. However, it is impractical to
> ask the working group to reach out to every vendor possible. For example,
> their are screen reader vendors in Japan. As chair I am going to draw a
> line there. We need to prove 2 implementations and although this is not a
> MUST statement I think for security we should try to get 2 implementations
> regardless. More than that is beyond what is required by the working group.
>
> Without committed support from more than just 2 AT Vendors, I think I
> would have to push back on the CfC and this proposed ARIA attribute fairly
> strenuously. As this thread has shown, this is more of a concern than you
> may want to admit, and in the case of Security and Privacy, I personally
> would tend to err on the side of caution.
>
>
> We have heard your input. I will ask to get support from 3 vendors. What
> we are asking for we already implemented in Screen Reader/2 and Screen
> Reader for Java - these products only spoke what was rendered and that
> includes for non password text fields. I am not using those for the example
> ATs but I already know this is doable.
>
> Joanie has committed to do it for Orca. I told Leonie I would work to get
> commitment from Freedom Scientific.
>
> ​​
> What I am concerned about and not a single person complaining has failed
> to address is text fields which are password fields but which the ATs
> always echo the characters typed which creates a security hole. I need the
> people who have issues to come up with a solution for that. This is one
> issue we are trying to resolve. I feel the group has adequately addressed
> the issue providing we get more than 2 AT vendors to agree to support it.
> This goes above and beyond what W3C requires especially given that these
> are SHOULDs.
>
> So far, I have tentatively agreed with Joanie's proposed fix for this
> problem as being a pragmatic compromise, but with caveats.
> Getting implemented support from Freedom, GW-Micro, Dolphin, Orca and NVDA
> would be a great start, but absent in your list is Voiceover, and failing
> to get Apple on board would be a huge gap in coverage - I would suggest a
> game-changer. As well, what of newer entrants into this field (Amazon's
> latest entry, which Peter Korn was showing at CSUN, Android TalkBack, etc.)?
>
> Finally, I am also somewhat concerned that you seem quite prepared to
> abandon the needs and expectations of non-North American screen reader
> users so blithely (ref: Japanese screen readers), simply in the interest of
> expediency. I fail to see how that benefits anyone, and have concerns
> around messaging that position going forward.
>
>
> John,  My point is that we don’t have enough bandwidth to canvas all the
> the possible screen reader vendors in the world. Leonie had given quite a
> long list of screen reader vendors. Also, some of these may require people
> to pay them to implement it. I have gone through that process. It is
> expensive. Since you want more than 2 implementations would you be willing
> to help us get them like working with Apple and NVDA?
>
> I will be reaching out to Freedom Scientific and AI Squared. Joanie has
> said she would implement it in Orca. Microsoft has found no security issues
> with the role so I see no reason why Narrator will not support it as part
> of their ARIA 1.1 support. If they agree that makes 4. You had asked for
> more than 2.
>
> Rich
>
>
> JF
>
> On Sat, Apr 2, 2016 at 7:34 AM, Richard Schwerdtfeger <
> richschwer@gmail.com> wrote:
>
>>
>> > On Apr 2, 2016, at 6:37 AM, Léonie Watson <tink@tink.uk> wrote:
>> >
>> >> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
>> >> Sent: 02 April 2016 12:22
>> >>
>> >> No. We spoke to Microsoft browser people. They did not believe we made
>> >> the problem worse.
>> >
>> > We also heard from Wendy Seltzer, who agreed that the proposed role
>> > definition represented a risk because of the possible discrepancy
>> between
>> > the visual and aural representations.
>> >
>>
>> Our revised text says the AT should read the actual rendered text. If the
>> AT reads the actual rendered text how is that a discrepancy between the
>> visual and aural rendering?
>>
>> Currently, without a password role the potential exists for a discrepancy
>> between the spoken text and obscured text with custom password fields.
>>
>> Backward compatibility issues will exist unless AT vendors can patch old
>> code or we create a custom password role in the AAPI mappings that allows
>> for a fallback to a text field which would be as insecure as the situation
>> is now where the user may or may not determine that they have a password
>> field and the text typed is spoken.
>>
>> >>
>> >> Our solution thus far actually narrows it for screen reader users.
>> >>
>> > No, I'm sorry, it doesn't. It changes the security risk, it doesn't
>> narrow
>> > it down. If anything the uncertainty factor makes it a much more serious
>> > problem.
>> >
>> > The updated role definition is a step in the right direction, but Jamie
>> Teh
>> > raises some valid points.
>> >
>> > We need to hear from other SR vendors including Apple, Dolphin and
>> > GWMicro/AISquared, and it would be helpful if we could point to wherever
>> > Freedom Scientific and others have expressed their commitment to
>> > implementing the role as described.
>> Apple has been copied but has not weighed in. They are a part of the ARIA
>> WG.
>>
>> I will ask Freedom to give you their response on the list.
>>
>> I have a to-do to reach out to other vendors - previous post. Dolphin and
>> GW Micro were on my list to reach out to. However, it is impractical to ask
>> the working group to reach out to every vendor possible. For example, their
>> are screen reader vendors in Japan. As chair I am going to draw a line
>> there. We need to prove 2 implementations and although this is not a MUST
>> statement I think for security we should try to get 2 implementations
>> regardless. More than that is beyond what is required by the working group.
>>
>> The
>>
>>
>> >
>> >> I asked Cynthia to reach out to Microsoft as I felt their browser team
>> > would
>> >> be more experienced in dealing with browser security issues than an
>> > interest
>> >> group. That said, who do you recommend I ask in the security ig? Are
>> they
>> >> active?
>> >
>> > Wendy offered a review by WebAppsSec. Perhaps we could take her up on
>> that
>> > offer?
>> >
>> > Léonie.
>> >
>> > --
>> > @LeonieWatson tink.uk Carpe diem.
>> >
>> >
>> >
>> >
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Consultant
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>
>
>


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

Advancing the mission of digital accessibility and inclusion