Re: Security Evaluation Request

Hi James,

Mostly because while yes, bad actors may not need role="password" to
continue to do 'evil' work, this also feels like a ready-made attribute to
aid their bad actions.

If the security review determines I'm daft (and the jury on that remains
out), then at least *I* will feel better knowing that we've at least looked
at this potential. With security and privacy, I am loathe to presume
anything.

JF

On Fri, Apr 8, 2016 at 12:57 PM, James Nurthen <james.nurthen@oracle.com>
wrote:

> 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>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> <http://www.oracle.com/>
> 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> <http://www.oracle.com/commitment> Oracle is
> committed to developing practices and products that help protect the
> environment
>
>
>
>
> --
> Regards, James
>
> [image: Oracle] <http://www.oracle.com>
> 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] <http://www.oracle.com/commitment> 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