RE: Security Evaluation Request

John,

So basically the definition of the proposed role=password is that the input text is being obfuscated visually, but may be available programmatically through Javascript/DOM (e.g. input[type=password]).

But my question to you is what type of inputs would people NOT fill out unless the input was visually obfuscated?

The primary one I can think of is password and PIN requests, so what are other examples based on your experience would people not complete (e.g. they expect the input to be obfuscated based on the request)?

Jon


From: John Foliot [mailto:john.foliot@deque.com]
Sent: Friday, April 08, 2016 5:08 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

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<mailto: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<mailto:john.foliot@deque.com>]
Sent: Friday, April 08, 2016 2:48 PM
To: Gunderson, Jon R <jongund@illinois.edu<mailto:jongund@illinois.edu>>
Cc: James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; Richard Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>; public-aria@w3.org<mailto: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<mailto: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<mailto:james.nurthen@oracle.com>]
Sent: Friday, April 08, 2016 12:57 PM
To: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>; 'Richard Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>

Cc: public-aria@w3.org<mailto: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<tel:703-225-0380>
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion



From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Friday, April 8, 2016 11:44 AM
To: James Nurthen <james.nurthen@oracle.com><mailto:james.nurthen@oracle.com>
Cc: public-aria@w3.org<mailto: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<mailto: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<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto: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

[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<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
[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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion



--
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion