RE: Security Evaluation Request

Hi Virginie,

 

FWIW, I too share the very same concerns – “…aligning a user context, and the behavior of the browser/tool…”

 

We have a 20+ year history of telling users that a password input has a certain level of ‘security’ attached to that concept, and I have expressed my concern that minting an attribute that suggests the same level of security, without a means of ‘enforcing’ that, presents in-and-of-itself a very real security issue. While I completely understand the positive benefits of creating such an ARIA role, I fear that the potential for malicious misuse has not been fully investigated.

 

We have been told today that authors are already doing this (a known problem), and we have also been told (repeatedly) that the browsers do not want to do much more with ARIA attributes than pass the information along to the Accessibility APIs (a concept, in principle, I support), yet here there may be an exception. 

 

One specific question I would want to pose to the security folks at the browser vendors would be this: would the browsers treat role=”password” with the same security considerations they already apply to <input type=”password”> - i.e. that the ARIA attribute would trigger a browser behavior with regard to ‘security enforcement’ (of the form you noted in your email)? 

 

This would be a departure from how browsers deal with ARIA attributes today.

 

Thanks.

 

JF

 

From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com] 
Sent: Tuesday, April 19, 2016 12:21 PM
To: Richard Schwerdtfeger <richschwer@gmail.com>
Cc: public-web-security@w3.org; ARIA <public-aria@w3.org>; tanvi@mozilla.com; gerv@mozilla.org; Mike Cooper <cooper@w3.org>; chaals@yandex-team.ru; dpranke@chromium.org; clown@alum.mit.edu; colingallagher.rpcv@gmail.com
Subject: RE: Security Evaluation Request

 

Richard, and all,

 

Some people mentioned also other possibilities do implement the password role outside ARIA with password or web component, I will leave that question to the web technologist. 

My concern is more aligning a user context, and the behavior of the browser/tool  : aka taking special care of the data. It seems to me that in terms of security, the creation of the role, password, is valuable if you have a secure expected usage associated. By secure, I mean, making sure the content is protected from direct reading on the screen, special protection against (including unexpected cloning or storage) *and* that the user is getting a sense of the sensitive situation he/she is dealing with, while entering the password (as mentioned by Chaals and others). 

 

Do you have the feeling that this conversation helped you to take a decision on the password role. 

 

Note that the Web Security IG will soon have a call, where we could address the remaining questions that you have on this. 

 

Regards,

Virginie

 

 

From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: mardi 5 avril 2016 20:39
To: GALINDO Virginie
Cc: public-web-security@w3.org <mailto:public-web-security@w3.org> ; ARIA; Mike Cooper
Subject: Security Evaluation Request

 

Virginie, 

 

I chair the ARIA Working group. We are considering a new ARIA role for ARIA 1.1 called “password”. The definition of this role is here.

 

https://rawgit.com/w3c/aria/password-role/aria/aria.html#password

 

For those who are not familiar with ARIA, ARIA semantics are added to web content so that User agents can then convey semantic information to assistive technologies running on the native platform using Accessibility APIs for the platform. Examples of assistive technologies might be: a screen reader for the blind, an alternate input device for the mobility impaired, or a screen magnifier for low vision users. 

 

The reason for the new role is that authors are creating custom password input fields instead of the native HTML input type=“password”. By applying a role=“password” to the input element we can convey to the assistive technology that the author intended it to be a password field vs an ordinary text field. Since these are custom password fields it is up to the author and not the user agent to handle the obscuring of text. 

 

example: <input type=“text” role=“password”>

 

The browser would convey to the assistive technology that this is a password field vs. an ordinary text field. In this scenario the user should pay attention to the text rendered. 

 

Does your group believe this adds security risks? If so, what are those risks? 

 

Thank you,

 

Rich Schwerdtfeger

ARIA Working Group Chair

  _____  

This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.