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

Hi Janina,

No insult intended. The point I am suggesting is that a non-sighted user,
"expecting" the standardized behavior of a "password" input would be doubly
surprised and disadvantaged if that alleged password field was simply one
in name alone, and that the other learned expectations you have for a
password input did not also follow along.

Creating an abstract "role" for an interaction widget that has over 2
decades worth of expected legacy behavior, without actually enforcing those
legacy behaviors, especially ones that relate to security and privacy, is
to me a recipe for some spectacular fails - that's all I'm suggesting here.

As well, it's not just the audio output: you may believe that it is a
password input (because the role told you so), but unless you have 100%
faith that the field is also being obscured, what then? I simply find this
troubling, that an author can make a declaration about a property of a
widget, declarations around security and privacy, and we do not appear to
have any mechanical way of enforcing that declaration. It is my belief that
it weakens any existing trust non-sighted users may already have when
dealing with password inputs.

Moving forward, Joanie's proposed solution appears workable as long as we
have implementation across all screen readers - a daunting task to
undertake to be sure, but what is the alternative? Partial implementation
and then hope for the best? I'm not comfortable with that, are you?

JF

On Mon, Apr 4, 2016 at 9:53 AM, Janina Sajka <janina@rednote.net> wrote:

> John Foliot writes:
> > Hi Cynthia,
> >
> > I agree, no contest.
> >
> > However, today's mobile web makes the likelihood of a bad actor doing bad
> > things here that much larger, a point I suspect you would also have to
> > agree on. It's not hard to imagine a scenario where a non-sighted user,
> > expecting the modicum of privacy and security that "password" has
> afforded
> > since it's inception in HTML 2.0 some 20+ years ago, may choose to
> interact
>
> Excuse me stepping in here, but I want to comment on this ...
>
> Of course a SR user will enter passwords in public places. The mobile
> device is intended to go were the user goes.
>
> However, it's rather a bit insulting to simply assume the user can't
> exercise good judgement regarding how to secure that interaction,
> perhaps by lowering the audio volume on the mobile device to a level
> that requires holding the phone close to the ear. Note that kind of
> touchpad keyboard entry is possible for the user who relies on TTS.
>
>
> It's not the circumstance that determines here, but how the circumstance
> is managed.
>
> Janina
>
>
> > with a password field in a public or semi-public setting: bus station,
> > cafeteria, shopping mall, etc. with that preconceived expectation
> >
> > It is, in fact, because of this legacy expectation that is part of the
> > problem now.
> >
> > JF
> >
> > On Sat, Apr 2, 2016 at 11:26 AM, Cynthia Shelly <cyns@microsoft.com>
> wrote:
> >
> > > Impersonating you at your bank website doesn’t require physical
> presence. Reading
> > > what you type over your shoulder does.
> > >
> > >
> > >
> > >
> > >
> > > *From:* John Foliot [mailto:john.foliot@deque.com]
> > > *Sent:* Tuesday, March 29, 2016 1:46 PM
> > > *To:* Cynthia Shelly <cyns@microsoft.com>
> > > *Cc:* Rich Schwerdtfeger <richschwer@gmail.com>; ARIA Working Group <
> > > public-aria-admin@w3.org>; Léonie Watson <tink@tink.uk>; Matt King <
> > > a11ythinker@gmail.com>
> > >
> > > *Subject:* RE: 7 Day Call for Consensus March 17, 2016 ARIA Working
> Group
> > > Resolutions
> > >
> > >
> > >
> > > > The attacks below rely on the bad actor being physically present to
> read
> > > the password over the user’s shoulder. The requirement for physical
> > > presence significantly reduces the risk.
> > >
> > > Using that logic Cynthia, I don't really need a password field when I
> do
> > > my banking at home, because I know I am alone. Yet, I encounter a
> password
> > > field every time I bank, because my bank will never know when or where
> I
> > > will fill out that input field. It's enhanced security for all
> occasions.
> > > Likewise for the non-sighted user.
> > >
> > > When a password field is introduced on a page, it's non-judgmental on
> any
> > > other aspect associated to its use: it's sole function is to obfuscate
> the
> > > text input for any user at any time. The risk associated to it is equal
> > > whether the user is home alone, or in the middle of Times Square on New
> > > Years Eve. The whole point of password inputs is when the user is not
> > > alone, and the edge case you note is identical for both the sighted
> user
> > > and the non-sighted user.
> > >
> > > JF
> > >
> > > On Mar 29, 2016 1:10 PM, "Cynthia Shelly" <cyns@microsoft.com> wrote:
> > >
> > > The goal of the password role is not to improve security. The goal is
> to
> > > improve user experience. It is no different than any other aria role in
> > > that. The web developer has already made a fake control with scripted
> > > behavior. The role just lets him tell the accessibility api what the
> > > control is supposed to be, so the accessibility api can tell the AT,
> and
> > > the AT can tell the user.
> > >
> > >
> > >
> > > The password role does not prevent accessing the content of the
> password
> > > field from script. It could, on some platforms, prevent accessing from
> the
> > > accessibility API. However, if malware is using the accessibility api
> from
> > > the OS side, the machine is already compromised.
> > >
> > >
> > >
> > > The attacks below rely on the bad actor being physically present to
> read
> > > the password over the user’s shoulder. The requirement for physical
> > > presence significantly reduces the risk.
> > >
> > >
> > >
> > > *From:* Matt King [mailto:a11ythinker@gmail.com]
> > > *Sent:* Tuesday, March 29, 2016 8:42 AM
> > > *To:* 'Rich Schwerdtfeger' <richschwer@gmail.com>; '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
> > >
> > >
> > >
> > > Since the discussions at CSUN, I have been giving this thought.
> > >
> > >
> > >
> > > As I understand it, we have 2 types of security exposure:
> > >
> > > 1.       With the password role as defined: blind users could type in
> an
> > > ARIA password field where, because input is audibly obscured, they
> will be
> > > unaware if the input is visible, especially if it were intentionally
> > > visible for nefarious reasons.
> > >
> > > 2.       Without the password role: blind users could type in a field
> and
> > > expose their password audibly because the screen reader didn’t
> > > automatically override its key echo function that announces which keys
> are
> > > pressed on the keyboard.
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > However, in the interest of preventing exposures for screen reader
> users
> > > who may have forgotten which key turns off key echo, and who do not
> have
> > > head phones handy, and who do not have time to lookup the required
> > > information, I have given some thought to requirements we could
> reasonably
> > > place on support for the password role that would resolve the conflict.
> > >
> > >
> > >
> > > We can not place a requirement on browsers to ensure the input is
> visually
> > > obscured. That would be requiring user agents to change behavior for
> all
> > > users, which would violate our long-standing principle to not do that.
> > >
> > >
> > >
> > > Instead, could we place a normative requirement on screen readers to
> do 2
> > > things when a password field is encountered:
> > >
> > > 1.       Automatically turn off key echo while focus is in the password
> > > field.
> > >
> > > 2.       If key echo was on, echo exactly what is typed in the field
> > > instead.
> > >
> > >
> > >
> > > Matt King
> > >
> > >
> > >
> > > *From:* Rich Schwerdtfeger [mailto:richschwer@gmail.com
> > > <richschwer@gmail.com>]
> > > *Sent:* Monday, March 28, 2016 3:25 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
> > >
> > >
> > >
> > > 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
> > > <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
> > > <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.
> > >
> > >
> > >
> > >
> >
> >
> > --
> > John Foliot
> > Principal Accessibility Consultant
> > Deque Systems Inc.
> > john.foliot@deque.com
> >
> > Advancing the mission of digital accessibility and inclusion
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                         sip:janina@asterisk.rednote.net
>                 Email:  janina@rednote.net
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa
>
>


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

Advancing the mission of digital accessibility and inclusion