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 <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>
> *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 <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> <http://www.oracle.com/>
>     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>
>     OracleCorporate 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

Oracle <http://www.oracle.com>
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 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment