Re: Security Evaluation Request

On Fri, 08 Apr 2016 19:17:32 +0200, Richard Schwerdtfeger  
<richschwer@gmail.com> wrote:

>
>> On Apr 8, 2016, at 11:10 AM, Chaals McCathie Nevile  
>> <chaals@yandex-team.ru> wrote:
>>
>> On Fri, 08 Apr 2016 15:38:53 +0200, Gervase Markham <gerv@mozilla.org>  
>> wrote:
>>
>>> On 06/04/16 21:27, Rich Schwerdtfeger wrote:
>>>> ARIA is not meant to be the web police. The reality is that people are
>>>> doing this in the wild and if you are interacting with one of these
>>>> things and you can’t see the screen you want to know what the intent  
>>>> of
>>>> the author is.
>>>
>>> So the target of this feature is people who care enough about web
>>> accessibility to include ARIA roles, but not enough to use semantic  
>>> markup?
>>
>> Yes. It seems to me that ARIA should just say "you must not make a  
>> custom password" until we discover that Web Components makes that a  
>> reasonable thing to do.
>
> The reason we are adding it is for custom password fields and ARIA is  
> not limited to use in Web Components.

Right.

> We could say that we don’t recommend authors use custom password fields  
> but I think they already made the decision irrespective of accessibility.

On the other hand, if they care enough to do accessibility, and we point  
out that they are effectively breaking accessibility and security  
together, unless we have a solution that really provides both out of the  
box, I expect that the decision to use a custom password would be  
re-examined.

>>>> So, we agree that people should not do this but if a user encounters  
>>>> it they need to know what it is for. Does adding the role attribute
>>>> with a value of “password" create a security problem that was not
>>>> there before?
>>>
>>> Well, it encourages people to use non-password fields for passwords,
>>> which is arguably a security problem because if people's password
>>> managers don't save the passwords, they are more likely to use bad
>>> (simple, short) passwords.
>>
>> That's one problem.
>>
>> Another is if it reports pseudo-passwords as if they are the same as  
>> real ones, the user doesn't know until they start feeding their  
>> password in whether or not it is going to have *minimal* protection, or  
>> will render the actual password.
>>
>> More seriously, browsers are likely to save the value for autocomplete  
>> unless they explicitly recognise the role as defining a real password  
>> field.

> I am not advocating customer passwords at all. That said we should  
> indicate the purpose of these elements. We could deal with this in the  
> mapping by providing separate information to the AT that this is some  
> form of custom password. This would be additional information that we  
> would not normally provide. IOW we map to all the traditional password  
> properties but we add something more that says this is a custom password  
> field.

I certainly think something like this is a better approach.

To be somewhat reliable, I think it might need to be recognised by  
browsers themselves, not *just* passed through to the accessibility API  
which is how most browsers handle ARIA. But maybe not…

Implementations that fudged the difference would be a reason *not* to  
agree to this.

cheers

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Saturday, 9 April 2016 00:05:56 UTC