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

On Mar 29, 2016 5:57 PM, "Gunderson, Jon R" <jongund@illinois.edu> wrote:
>
> John,
>
> Seems to be the bigger question you raise is the security issues for all
users whether or not they are using an assistive technology.

Yes and no. We are currently discussing an attribute that will inform the
screen reader user, who cannot see the screen, that the custom input that
is asking for thier password is at least as secure as the standard input
type of "password".

But is it? The non-sighted user cannot visually verify that the characters
are actually being obfuscated, they have to rely solely on audio feedback,
and by simply slapping an attribute on the custom control it will
"announce" that the field is being obfuscated, whether true or not. Large
ethical companies will likely ensure that the scripted function behind that
custom control *is* providing the appropriate obfuscation, but what about
Jack Blackhat, who has far less scrupples than Microsoft or IBM?

>
> The use of any non-standard authentication methods seems to be a
potential security issue for all users.

Correct. To then offer up an attribute who's sole function is to tell the
non-sighted user that a potentially insecure input is a password field
further advances that concern. It is a standardized spoof, and once a few
blind users get stung this way, they will quickly become suspicious of
*all* inputs announced as "password". I fail to see how that is progress.

>
> Is there anyway the W3C can prevent people from creating custom
username/password controls or authentication methods in general (e.g.
biometrics, gestures)?
>

No, because the W3C is not the Internet police.

However, we shouldn't be making it easier to abuse this ability by crafting
an attribute that simply tells AT this thing has a low level of security,
without also ensuring that this expectation is, in fact, correct. The
current proposed attribute can't do that today.

>
> The question for ARIA seems to be how can ARIA specification (e.g. if the
author includes the ARIA markup) be used to orient users that the
authentication method being used is non-standard and potentially a security
risk either because it may not be compatible with assistive technologies or
is not secure to any user.
>

I currently believe that the only way we can achieve what we want here is
to get the browsers on board: that any input that claims to be a password
field, either by using <input type="password">, or via role="password"
behave identically the same way; that the integrity of the Screen Reader
announcement is *at the browser level*, and not at the page author level.
That is where the current trust around password inputs live today, and if
the non-sighted user has to trust someone, better it be the browser than
Mr. Blackhat.

My suspicion today is that the browser vendors will initially balk at that,
but it may still be worth asking, *because* of the security concern.

JF

>
> Jon
>
>
>
>
>
> From: John Foliot [mailto:john.foliot@deque.com]
> Sent: Tuesday, March 29, 2016 4:02 PM
>
> To: Gunderson, Jon R <jongund@illinois.edu>
> Cc: Rich Schwerdtfeger <richschwer@gmail.com>; Léonie Watson <tink@tink.uk>;
ARIA Working Group <public-aria-admin@w3.org>
> Subject: RE: 7 Day Call for Consensus March 17, 2016 ARIA Working Group
Resolutions
>
>
>
>
> On Mar 29, 2016 4:34 PM, "Gunderson, Jon R" <jongund@illinois.edu> wrote:
> >
> > John,
>
>
>
>
> >
> > Verification of whether an ARIA role is being used properly by an
author, whether it is for “Password”s or other ARIA roles, seems beyond the
scope of the specification.  The specification and authoring practices
guide should define where the role should be used and if “password” is a
special case where it should not be used.
>
> I wish it was that simple Jon, but it isn't. While you might argue it is
out of scope for the ARIA WG, I believe it *is* in scope for the W3C: we
can't just throw our hands up and say security is out of scope: "passwords"
are inherently related to security, and subject to responsible use. An
authoring guide that scolds folks for improper usage isn't enough IMHO.
>
> >
> > People who want to “fool” screen reader users into giving up their
passwords will find ways to do it with or without role=password.
>
> Sure, but we also have a responsibility to not hand it to the bad actors
on a silver plate.
>
> >
> > The main question I believe the working group needs to determine is if
there is a compelling use case for role=password that will be beneficial to
assistive technology users.
>
> Well, I think Rich has already brought forward the use cases. This is now
less of a "why?" question and more of a "How?" question today.
>
> JF
>
> >
> >
> >
> > Jon
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: John Foliot [mailto:john.foliot@deque.com]
> > Sent: Tuesday, March 29, 2016 2:49 PM
> > To: Gunderson, Jon R <jongund@illinois.edu>
> > Cc: Rich Schwerdtfeger <richschwer@gmail.com>; ARIA Working Group <
public-aria-admin@w3.org>; Léonie Watson <tink@tink.uk>
> >
> > Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working Group
Resolutions
> >
> >
> >
> > Hi Jon,
> >
> > I agree. The concern though is one of trust: non-sighted users are
trusting their browser and AT to be accurate here.
> >
> > Allowing authors to add a role that suggests some form of security,
without that security being implemented at the browser/AT level, means
those users have to trust the page author when they 'wisper' to the
non-sighted user "ya, this is secure", when, in fact, it may not be. Simply
having a special role that does nothing more than suggest it's secure does
nobody any favors. You could just as easily use aria-label="password field"
and be equally secure (or non-secure, as the case may be).
> >
> > In other words, if we are looking to establish a generic password
labelling mechanism, we need to ensure it also meets ALL of the expected
security & privacy requirements already know to be associated with that
input type; we must ensure it is indeed a password field in more than name
alone.
> >
> > JF
> >
> > On Mar 29, 2016 9:46 AM, "Gunderson, Jon R" <jongund@illinois.edu>
wrote:
> >>
> >> +1
> >>
> >>
> >>
> >> I think we need to remember that ARIA describes the user interface, it
does not define the user interface.
> >>
> >>
> >>
> >> If there are user interface components that are not being defined by
native semantics of the markup language, we need to make sure we have the
vocabulary in ARIA to accurately describe them to assistive technologies.
> >>
> >>
> >>
> >> Jon
> >>
> >>
> >>
> >>
> >>
> >> From: Rich Schwerdtfeger <richschwer@gmail.com>
> >> Date: Monday, March 28, 2016 at 5:24 PM
> >> To: John Foliot <john.foliot@deque.com>
> >> Cc: Léonie Watson <tink@tink.uk>, ARIA Working Group <
public-aria-admin@w3.org>
> >> Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working
Group Resolutions
> >> Resent-From: <public-aria-admin@w3.org>
> >> Resent-Date: Monday, March 28, 2016 at 5:25 PM
> >>
> >>
> >>
> >> John,
> >>
> >>
> >>
> >> First, authors are already creating these custom password fields to
say that they must behave exactly like an HTML5 password field does not
make any sense. The Microsoft security people stated that people were doing
this already and adding a password role does absolutely nothing to stop
them from doing so.
> >>
> >>
> >>
> >> The far bigger security issue is that despite the fact that they are
creating one of these custom fields we give the author zero vehicle to tell
the screen reader to not ECHO the keyboard keys being type for all to hear
in the room. They don’t echo the keys you actually see which are obscured.
they echo the text typed coming in from the keyboard.
> >>
> >>
> >>
> >> What is your solution to prevent this? Yelling at them to use HTML5
passwords is like our shouting at the moon.
> >>
> >>
> >>
> >> I want to see a real solution here.
> >>
> >>
> >>
> >> Where are we asking a browser to change their UI? Browser vendors have
been very clear to tell us that we cannot require them to change their UI
based on ARIA. On this I see no win although I agree with you that it would
be could here.
> >>
> >>
> >>
> >> So, the net of this if we don’t include the role we continue to leave
users exposed with a security hole where everyone can hear the password
they are typing unless they happen to have a headset on. Is that what you
both want?
> >>
> >>
> >>
> >>
> >>
> >> Rich Schwerdtfeger
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> On Mar 28, 2016, at 5:02 PM, John Foliot <john.foliot@deque.com>
wrote:
> >>>
> >>>
> >>>
> >>> Hi Rich,
> >>>
> >>>
> >>>
> >>> After chatting with some folks at CSUN, I share Leonie’s concerns.
Unless all of the browser vendors and screen readers are going to
programmatically treat the role=”password” *EXACTLY* like input
type=”password” I too see a serious security/privacy concern.
> >>>
> >>>
> >>>
> >>> For example, what should we expect with this piece of code: <input
type=”text” role=”password”>?
> >>>
> >>>
> >>>
> >>> Will screen readers announce “star, star, star” while displaying
“Secret PIN #” in the text field, in the clear and open?  (Saying they
shouldn’t do that  isn’t enough, I just did it and so others will as well)
> >>>
> >>>
> >>>
> >>> Likewise for a scripted input, perhaps something like <div
class=”Input_Field” role=”password”>: how do we guarantee end users that
the scripted input *is* being treated like an actual password input, and
isn’t a fishing spoof on non-sighted users? Companies like IBM would likely
never do that, but IBM isn’t the only folks writing code out there :D
> >>>
> >>> I also understand that this is needed for SVG, so my concern is not
that we need a “something”, but rather, again, we’re asking browser vendors
to change their UI based upon an ARIA attribute, something that they have
refused to do in the past, as for example here:
https://lists.w3.org/Archives/Public/public-pfwg/2015Sep/0172.html
> >>>
> >>>
> >>>
> >>> JF
> >>>
> >>>
> >>>
> >>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
> >>> Sent: Monday, March 28, 2016 5:37 PM
> >>> To: Léonie Watson <tink@tink.uk>
> >>> Cc: ARIA Working Group <public-aria-admin@w3.org>
> >>> Subject: Fwd: 7 Day Call for Consensus March 17, 2016 ARIA Working
Group Resolutions
> >>>
> >>>
> >>>
> >>> Leonie,
> >>>
> >>>
> >>>
> >>> Did my response address your concern? Microsoft confirmed that people
were creating their own custom passwords in the wild and there is no ARIA
role to indicate to the AT that this is a password and to tell the AT to
NOT echo the password text as you type it. This would facilitate that.
> >>>
> >>>
> >>>
> >>> Rich
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Rich Schwerdtfeger
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> Begin forwarded message:
> >>>>
> >>>>
> >>>>
> >>>> From: Rich Schwerdtfeger <richschwer@gmail.com>
> >>>>
> >>>> Subject: Re: 7 Day Call for Consensus March 17, 2016 ARIA Working
Group Resolutions
> >>>>
> >>>> Date: March 20, 2016 at 3:59:23 PM CDT
> >>>>
> >>>> To: tink@tink.uk
> >>>>
> >>>> Cc: ARIA Working Group <public-aria-admin@w3.org>
> >>>>
> >>>>
> >>>>
> >>>> Leonie,
> >>>>
> >>>>
> >>>>
> >>>> On the other hand, a screen reader could announce the characters
being typed and not know to not do that. Furthermore, people are creating
these things today and there is no way to know that the textfield is a
password field. Would you prefer to not know?
> >>>>
> >>>>
> >>>>
> >>>> I don’t understand how your statement supports your argument.
Incidentally,we did vet this with the Microsoft browser security people
before agreeing to add it to the spec. Microsoft stated that people were
creating their own password textbooks in the wild and there is no way for
you to know that is what the textfield is.
> >>>>
> >>>>
> >>>>
> >>>> Rich
> >>>>
> >>>>
> >>>>
> >>>> Rich Schwerdtfeger
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> On Mar 17, 2016, at 3:06 PM, Léonie Watson <tink@tink.uk> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
> >>>>> Sent: 17 March 2016 19:12
> >>>>> To: ARIA Working Group <public-aria-admin@w3.org>
> >>>>> Subject: 7 Day Call for Consensus March 17, 2016 ARIA Working Group
Resolutions
> >>>>>
> >>>>> This is a Call for Consensus (CfC) to the Accessible Rich Internet
Applications (ARIA) Working Group on the following resolution:
> >>>>>
> >>>>> 1. Accept Joanie’s addition of a new password addressing Action
2004:
> >>>>>
> >>>>> https://rawgit.com/w3c/aria/password-role/aria/aria.html#password
> >>>>>
> >>>>>
> >>>>>
> >>>>> I object to the password role. Unless I’m missing something, it
leaves open the possibility that an AT will behave as though the characters
input into the field are obscured, when visually they may not be. A screen
reader user cannot be certain that their password is adequately protected
from being observed.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Léonie.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> @LeonieWatson tink.uk Carpe diem.
> >>
> >>