Re: Password role proposal: Freedom Scientific response

You are talking about a hacker getting into the GW site vs. a site that is used by everyone with the explicit intent of duping a blind user. What you are talking about is overall hacking of sites and code. 

Sorry, I am not biting on the drama. 

Rich Schwerdtfeger




> On Apr 25, 2016, at 11:26 AM, John Foliot <john.foliot@deque.com> wrote:
> 
> > I highly doubt any author would intentionally write code to dupe blind users.
>  
> Seriously Rich? That has got to be one of the most naive comments I’ve read in a very long time. We have documented cases *TODAY* of malicious code being deliberately directed toward Blind users: http://en.blog.nic.cz/2015/02/17/cyber-attacks-against-handicapped/ <http://en.blog.nic.cz/2015/02/17/cyber-attacks-against-handicapped/>
>  
> You don’t think that there are bad actors out there, quite willing to take advantage of *anyone* they can, without a care of the individual? That these criminals will write code to take advantage of any user, any vulnerability, and really don’t give a toss?
> 
> You are suggesting that we should ignore the fact that Identity theft victims in the United States in 2014 accounted for roughly seven percent of the country’s adult population? The Department of Justice’s Bureau of Justice Statistics announced that figures for 2014 suggest an estimated 17.6 million Americans older than 16 had their personal information compromised at least once during the last calendar year. 
> (source: http://www.washingtontimes.com/news/2015/sep/28/identity-theft-affected-176-million-cost-154-billi/ <http://www.washingtontimes.com/news/2015/sep/28/identity-theft-affected-176-million-cost-154-billi/>) 
>  
> I’m sorry, I guess you are just more trusting than I am: willfully thinking that this is an unlikely scenario is what is “over the top” – and I am quite troubled that you can be as dismissive as you just were (your last comment in particular was uncalled for, and does nothing to advance this discussion. I expect better than that.)
>  
> JF
>  
>   <>
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Monday, April 25, 2016 10:36 AM
> To: John Foliot <john.foliot@deque.com>
> Cc: Birkir Gunnarsson <birkir.gunnarsson@deque.com>; public-aria@w3.org; tink@tink.uk
> Subject: Re: Password role proposal: Freedom Scientific response
>  
> John,
>  
> I highly doubt any author would intentionally write code to dupe blind users. 
>  
> I am sorry but that is over the top. 
>  
> Next time I walk out the door I need to look up to see if a house is going go fall on me. 
>  
> Rich
>  
> Rich Schwerdtfeger
>  
>  
> 
>  
>> On Apr 25, 2016, at 10:30 AM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>> wrote:
>>  
>> While I do have some concerns around user-awareness, my concerns are more focused on authors who might deliberately seek to fool non-sighted users. 
>> 
>> For the past 20+ years, we have had a mental concept of “password” on the web, complete with the expected behaviors and related security checks we instinctively expect of an input of “type=password”. These include a ‘guarantee’ (for example) that characters will be obfuscated on screen as a default, and that content entered into this type of input cannot be copied and pasted: these are standardized functions/features enforced at the browser level, and cannot be over-ridden by the content author.
>> 
>> We will not have that same confidence when any author can open a text editor and suggest to those users who are dependent on ARIA attribute information, that a custom widget is somehow “secure” because, “hey, I told you it is”. While the non-sighted user is more likely to believe this statement from a content author such as IBM or Google, on today’s web, they are but two of the millions of web-page authors who will be able to use this attribute, and without the ability to have some kind of behavior enforcement I assert this attribute will remain a serious security concern, ripe for misuse and abuse: <div class=”really_crappy_not_secure_input_widget” role=”password”></div>
>>  
>> Birkir, I think adding an additional attribute of “aria-custom-password” might help well-intentioned authors to better do the right thing; it still does not address the malicious author intent on fooling you into believing that something is more secure than it actually is. Rich has suggested that “…It will require changes in AT behavior and end-user education…” however I also assert that it will require some changes at the browser level: *if* browsers treat role=”password” the same way they treat type=”password” then we’ve got (I believe) a solution. 
>>  
>> Minus the browser support however, you are only addressing a part of the total ‘stack’ of tools and applications that is today’s web platform for non-sighted users. (i.e. for this, it’s more than just what the screen readers report).
>> 
>> JF
>> 
>> 
>>  
>> From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com <mailto:birkir.gunnarsson@deque.com>] 
>> Sent: Monday, April 25, 2016 9:57 AM
>> To: 'Rich Schwerdtfeger' <richschwer@gmail.com <mailto:richschwer@gmail.com>>; tink@tink.uk <mailto:tink@tink.uk>
>> Cc: 'Rich Schwerdtfeger' <schwer@us.ibm.com <mailto:schwer@us.ibm.com>>; public-aria@w3.org <mailto:public-aria@w3.org>
>> Subject: RE: Password role proposal: Freedom Scientific response
>>  
>> I am much more onboard with the idea if we add the “aria-custom-password” attribute along with the password role.
>>  
>>  
>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
>> Sent: Monday, April 25, 2016 9:35 AM
>> To: tink@tink.uk <mailto:tink@tink.uk>
>> Cc: Rich Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com>>; public-aria@w3.org <mailto:public-aria@w3.org>
>> Subject: Re: Password role proposal: Freedom Scientific response
>>  
>> I would agree with that statement. Security should be what is important. 
>>  
>> I would interpret this is that if the ARIA spec. says ATs SHOULD expose the rendered text vs. the star star star approach then we should expect them to do that in the future as they have publicly committed to supporting ARIA.
>>  
>> If it is not in the ARIA spec. we may never see it in JAWS. 
>>  
>> This is our opportunity to get them to do things correctly by putting it in the ARIA spec. One thing we might do, however, is to also expose an additional attribute at the platform layer to indicate these are custom password roles. 
>>  
>> This would address some of John’s concerns about not knowing that this is a custom password field. It will require changes in AT behavior and end-user education. 
>>  
>> Thoughts? 
>>  
>> Rich
>>  
>>  
>> Rich Schwerdtfeger
>>  
>>  
>> 
>>  
>>> On Apr 25, 2016, at 3:32 AM, Léonie Watson <tink@tink.uk <mailto:tink@tink.uk>> wrote:
>>>  
>>> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com <mailto:schwer@us.ibm.com>] 
>>> Sent: 22 April 2016 19:30
>>> “Following up on Leonie's request to contact ATVs. I contacted Freedom Scientific's CTO regarding the changes we have put in the ARIA password role regarding what ATs should do in response to speaking the actual text rendered.
>>>  
>>> Statement from Glen Gordon at FS:
>>> Freedom Scientific actively embraces ARIA. We recognize that this is an evolving standard and do our best to support newly added items in a timely fashion.”
>>>  
>>> Thanks for following up on this Rich. I understand that FS is reluctant to commit to a particular course of action, and I daresay they wouldn’t be the only ones if we were to reach out to other proprietary screen reader vendors.
>>>  
>>> “They have a policy to not commit to dates or product features publicly so this is as good as it gets.”
>>>  
>>> A commitment to implement the password role is understandably something FS might be reluctant to provide, but a general commitment to protecting consumer security would have been better than this.
>>>  
>>> As things stand we do not have a clear commitment from any screen reader vendor other than Orca, that the password role will be implemented in a secure way. This is troubling.
>>>  
>>>  
>>> Léonie.
>>>  
>>> -- 
>>> @LeonieWatson tink.uk <http://tink.uk/> Carpe diem