Re: Risks the password role does create

On 22/06/2016 1:58 PM, Richard Schwerdtfeger wrote:
> Well,
>
> Michael, as it turns out input type=“password” is not secure either. I 
> will be filing an APA issue.
>
This does bring up some concerns about the bar we should meet. One 
argument in the WG against the password role (though properly I think 
that is an argument against custom passwords, not the role per se) is 
that HTML passwords are more secure. But the HTML 5.1 password spec 
<https://www.w3.org/TR/html51/sec-forms.html#password-state-typepassword> 
doesn't say much about the security protections user agents provide, 
aside from "The user agent should obscure the value so that people other 
than the user cannot see it." For custom password fields, that would be 
an author responsibility, regardless of whether they use the password role.

I can't find any other guidance in the HTML spec about protecting 
password fields, and this has likely been true for several versions. 
Maybe there is some de facto security implemented long ago by most 
browsers so there wasn't seen a need to address it in the spec, though 
since a main goal of HTML 5 was to document existing browser behavior, 
it's a surprise this didn't come up. I don't have information about what 
proportion of user agents do provide that security, and wonder if 
interoperability testing data exists on this. If Rich has found 
implementations that don't meet the level of security we assume, then it 
brings further questions about whether comparing to HTML should be a 
reason for decisions we make on the ARIA feature.

At the moment I think the draft ARIA password role text has more 
security guidance for AT and authors than the HTML spec.

Michael