Re: Security Evaluation Request

That is my opinion as well.

Sent from my iPhone

> On 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
>>  
>> 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> 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>
>> James Nurthen | Principal Engineer, Accessibility
>> Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video: james.nurthen@oracle.com 
>> Oracle Corporate Architecture
>> 500 Oracle Parkway | Redwood Cty, CA 94065 
>> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
> 
> -- 
> Regards, James
> <oracle_sig_logo.gif>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video: james.nurthen@oracle.com 
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood Cty, CA 94065 
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment