Re: Security Evaluation Request

"ARIA semantics are added to web content so that User agents can then
convey semantic information to assistive technologies running on the native
platform using Accessibility APIs for the platform. Examples of assistive
technologies might be: a screen reader for the blind, an alternate input
device for the mobility impaired, or a screen magnifier for low vision
users."

https://rawgit.com/w3c/aria/password-role/aria/aria.html#password

"The password role makes it possible for assistive technologies
 to customize their behavior in order to not inadvertently expose
private information. For instance, a screen reader which normally echoes
 key presses might instead remain silent or echo each displayed
character as it is inserted. In order to facilitate the latter behavior,
 authors SHOULD set the password element's text to
characters which obscure the real value, when that value is obscured on
screen. Authors SHOULD also update that text each time a character is
inserted or deleted by the user."


*My comments on the above paragraph:  Seems to me that where it says
"SHOULD," the language could be improvedby substituting "MUST."
(However, please see additional comments below.)*

"In order to ensure that passwords will not be overheard during input,
assistive technologies SHOULD NOT echo key presses of printable characters
when an element with role password has focus, unless the user has
explicitly enabled this option. If the user has enabled key echo, assistive
technologies SHOULD present each rendered character as it is inserted
rather than speaking a predetermined character, such as "star.""


*My comments on the above paragraph:  The language "unless the user
has explicitly enabled this option" needs *


*to be removed and replaced with "unless the user has selected an
option, using the assistive technology, to*


*briefly enable a password reminder or password (view, listen, or
touch) option."*


*I am assuming here that it is important to protect the privacy of
users (this seems vitally important to me),*



*but also that there are users that might only be able to hear and not
have full uses of other senses
<https://www.sense.org.uk/content/deafblindness-and-other-senses>.*


*Thus, my suggested modifications are an attempt to address the users'
needs for both privacy and accessibility, for *


*users that actually require assistive technology (as not all users do).*



*My overall comments / questions:  *Curious how this would relate to
technologies that don't rely upon passwords, but do interface with or
partially rely upon assistive technologies, including those which could
allow the user to obtain information or transact over the web.  Examples of
such technology (that does not rely upon a password) would be Emercoin,
InfoCard, launchkey, etc.

Cheers,

Colin

On Fri, Apr 8, 2016 at 10:17 AM, Richard Schwerdtfeger <richschwer@gmail.com
> wrote:

>
> > On Apr 8, 2016, at 11:10 AM, Chaals McCathie Nevile <
> chaals@yandex-team.ru> wrote:
> >
> > On Fri, 08 Apr 2016 15:38:53 +0200, Gervase Markham <gerv@mozilla.org>
> wrote:
> >
> >> On 06/04/16 21:27, Rich Schwerdtfeger wrote:
> >>> ARIA is not meant to be the web police. The reality is that people are
> >>> doing this in the wild and if you are interacting with one of these
> >>> things and you can’t see the screen you want to know what the intent of
> >>> the author is.
> >>
> >> So the target of this feature is people who care enough about web
> >> accessibility to include ARIA roles, but not enough to use semantic
> markup?
> >
> > Yes. It seems to me that ARIA should just say "you must not make a
> custom password" until we discover that Web Components makes that a
> reasonable thing to do.
> >
>
> The reason we are adding it is for custom password fields and ARIA is not
> limited to use in Web Components.
>
> We could say that we don’t recommend authors use custom password fields
> but I think they already made the decision irrespective of accessibility.
>
>
> >>> So, we agree that people should not do this but if a user encounters it
> >>> they need to know what it is for. Does adding the role attribute with a
> >>> value of “password" create a security problem that was not there
> before?
> >>
> >> Well, it encourages people to use non-password fields for passwords,
> >> which is arguably a security problem because if people's password
> >> managers don't save the passwords, they are more likely to use bad
> >> (simple, short) passwords.
> >
> > That's one problem.
> >
> > Another is if it reports pseudo-passwords as if they are the same as
> real ones, the user doesn't know until they start feeding their password in
> whether or not it is going to have *minimal* protection, or will render the
> actual password.
> >
> > More seriously, browsers are likely to save the value for autocomplete
> unless they explicitly recognise the role as defining a real password field.
> >
>
> I am not advocating customer passwords at all. That said we should
> indicate the purpose of these elements. We could deal with this in the
> mapping by providing separate information to the AT that this is some form
> of custom password. This would be additional information that we would not
> normally provide. IOW we map to all the traditional password properties but
> we add something more that says this is a custom password field.
>
> > cheers
> >
> > --
> > Charles McCathie Nevile - web standards - CTO Office, Yandex
> > chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>
>