Re: Security Evaluation Request

Jon,

Sure, but I think you are missing the larger point: an input of
type=password (or role="password") can and will be used for more than
*JUST* an actual password, and so assuming that the label for such an input
field will always be <label>Password</label> is a stretch.

JF

On Fri, Apr 8, 2016 at 4:07 PM, Gunderson, Jon R <jongund@illinois.edu>
wrote:

> John,
>
>
>
> It seems most forms that I fill out that require a social security number
> do not obfuscate the characters I enter.
>
>
>
> Are there some able bodied people who would stop filling out a form if
> controls with certain labels (e.g. social security number) are not
> obfuscating their input?
>
>
>
> Jon
>
>
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Friday, April 08, 2016 2:48 PM
> *To:* Gunderson, Jon R <jongund@illinois.edu>
> *Cc:* James Nurthen <james.nurthen@oracle.com>; Richard Schwerdtfeger <
> richschwer@gmail.com>; public-aria@w3.org
>
> *Subject:* Re: Security Evaluation Request
>
>
>
> Hi Jon,
>
>
>
> That appears to be a somewhat simplistic view. I have seen previously the
> use of <input type="password"> to collect other sensitive data, for example
> social security numbers, and in those instances the <label> (or equivalent)
> would NOT be "Password", and so I think it would be reasonable to conclude
> that a custom input widget would likely also be used for similar "sensitive
> data" collection, above and beyond just a password.
>
>
>
> Ya?
>
>
>
> JF
>
>
>
> On Fri, Apr 8, 2016 at 1:23 PM, Gunderson, Jon R <jongund@illinois.edu>
> wrote:
>
> I assume these custom password controls will have a label (e.g. using the
> LABEL element or other labeling technique)  of “Password”, so people will
> know the control is a password control without using the role=password.
>
>
>
> Isn’t having a role=password at least providing a means to identify the
> custom password control in a way that supports internationalization, and
> reducing any ambiguity of the purpose and caution an assistive technology
> user should take when interacting with the control?
>
>
>
> Jon
>
>
>
>
>
> *From:* James Nurthen [mailto:james.nurthen@oracle.com]
> *Sent:* Friday, April 08, 2016 12:57 PM
> *To:* John Foliot <john.foliot@deque.com>; 'Richard Schwerdtfeger' <
> richschwer@gmail.com>
>
>
> *Cc:* public-aria@w3.org
> *Subject:* Re: Security Evaluation Request
>
>
>
> John,
> My issue with this whole "evil author" thing is that an "evil author" can
> do exactly what you are talking about today without the need for a password
> role. Why are we getting hung up on this?
> Regards,
> James
>
> On 4/8/2016 10:54 AM, John Foliot wrote:
>
> Hi all,
>
>
>
> Outside of SVG, are there any other W3C mark-up languages where this is a
> problem?
>
> Is the lack of ability to create a password field in SVG the primary
> driver of this request/need today?
>
> Could the “native semantic” issue (and related security/privacy concerns)
> be dealt with inside of the SVG spec instead?
>
>
>
> One of my ongoing concerns is with giving an author (any author, from IBM
> or Oracle to Dr. Evil and his Merry Band of Tricksters) a carte-blanche
> ability to imply some sense of security and privacy on a custom,
> author-supplied widget. Saying we can't impose behavior on a custom control
> via ARIA is one thing, turning around and giving authors the ability to be
> untruthful about it is a whole other kettle of fish, and I am troubled that
> we may not be looking at how this proposed attribute might be used
> maliciously, with the express attempt to deceive.
>
>
>
> It is my hope that this question also be contemplated in a security review.
>
>
>
> JF
>
> ​--
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Austin, TX
>
>
>
> Deque Systems Inc.
> 2121 Cooperative Way, Suite 210,
> Herndon, VA 20171-5344
>
> Office: 703-225-0380
>
> john.foliot@deque.com
>
>
>
> *Advancing the mission of digital accessibility and inclusion*
>
>
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:richschwer@gmail.com
> <richschwer@gmail.com>]
> *Sent:* Friday, April 8, 2016 11:44 AM
> *To:* James Nurthen <james.nurthen@oracle.com> <james.nurthen@oracle.com>
> *Cc:* public-aria@w3.org
> *Subject:* Re: Security Evaluation Request
>
>
>
> You cannot make an accessible password field in SVG without it.
>
>
>
> On Apr 8, 2016, at 11:40 AM, James Nurthen <james.nurthen@oracle.com>
> wrote:
>
>
>
>
>
> On 4/8/2016 9:37 AM, Gervase Markham wrote:
>
> On 08/04/16 17:22, Richard Schwerdtfeger wrote:
>
> Companies do not use standard HTML markup when they feel it does not
>
> meet their needs. It really does not have anything to do with whether
>
> the markup is semantically correct. This is happening now and we
>
> don’t even have a password role. Companies that must do this for
>
> business reasons need a way to make it accessible.
>
> They have a way to make it accessible - use a proper password field. So
>
> what you are asking for is actually a second way to make it accessible.
>
> What happens if some company then comes forward and says they can't use
>
> your solution because for security reasons they aren't allowed to label
>
> the field "password" in any way. What do you do then? Invent an alias
>
> and call it "type='mrblobby'"?
>
>
>
> There is only a certain distance one should go to accommodate ridiculous
>
> corporate requests. "We want to do passwords but don't want to use
>
> password fields" is a user-hostile request (both for users requiring
>
> accessibility technology and other users) and should be treated as such.
>
> How can someone create a password field in SVG without this?
>
> Regards,
> James
>
>
>
>
> The bigger issue is that passwords as a technology have long outlived
>
> their usefulness. The growing world aging population has issues
>
> remembering passwords for all the sites they have to gain access to
>
> so they often use a simple, short, easy to remember password across
>
> all the sites creating a security issue. To this end even HTML’s
>
> password is a security risk as it is much easier to hack. This can
>
> result in identity theft and a whole litany of issues. Captchas are
>
> also a huge problem for aging users.
>
> This may be so; but encouraging people to use non-password fields for
>
> passwords and so avoiding all the software people are using to help them
>
> manage the password problem (which does make things better) doesn't help.
>
>
>
> Gerv
>
>
>
>
>
> --
> Regards, James
>
> <oracle_sig_logo.gif>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com_&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=qR1G-AqvG7bBAGsi8MrDKDeU6g3O3BCZ1J3nZtEbzbA&e=>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
> <+1%20415%20987%201918> | Video: james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood Cty, CA 94065
> <green-for-email-sig_0.gif>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com_commitment&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=x-IS-XAc3vrKpeTTukDTHutjPgkPg5WJZKOaitYVHbM&e=> Oracle
> is committed to developing practices and products that help protect the
> environment
>
>
>
>
>
> --
> Regards, James
>
> [image: Oracle]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=I5TNORjxknLRRVIrziQprUfKJHO0exksHZbqkPxv0UE&e=>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
> <+1%20415%20987%201918> | Video: james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood Cty, CA 94065
> [image: Green Oracle]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oracle.com_commitment&d=BQMDaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=uhX5J3P9bIgIXsGoFe0EGNeZYeWbKXQTcAa2yMwBJus&s=x-IS-XAc3vrKpeTTukDTHutjPgkPg5WJZKOaitYVHbM&e=>Oracle
> is committed to developing practices and products that help protect the
> environment
>
>
>
>
>
> --
>
> 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