Closed Bug 415944 Opened 13 years ago Closed 13 years ago

Don't expose password text through A11y text interfaces

Categories

(Core :: Disability Access APIs, defect, P1)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access, privacy)

Attachments

(1 file)

In the old MSAA text interfaces we made sure not to expose password text.

We need to do the same thing for the new IAccessibleText and AtkText in beta 3, in order to make sure that passwords are not read aloud.

Being able to insert password text, however, needs to remain, in order for alternative input software users to be able to enter passwords.
Flags: blocking1.9?
Keywords: privacy
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Attachment #301694 - Flags: review?(surkov.alexander)
Comment on attachment 301694 [details] [diff] [review]
Expose one * for each real character in the password

What about aria_secret support?
(In reply to comment #2)
> (From update of attachment 301694 [details] [diff] [review])
> What about aria_secret support?
> 

I mean if "this" is editable document and it has a protected content child. We should catch it as well.

Also, what is the parent is protected content node but its children aren't?
True, but that would be weird. I don't think we should walk up the parent chain for that. I'm not sure the extra processing would be worthwhile.

aria_secret will cause nsIAccessibleRole::ROLE_PASSWORD_TEXT

There could be an argument that aria_secret should be removed from the spec and make the author use a real password field.
Hmm. Thinking about it more. I don't think they should allow an ARIA password field at all.
Comment on attachment 301694 [details] [diff] [review]
Expose one * for each real character in the password

we expose text leaf accessible under html:input therefore technically it's possible to announce private text in IA2 I guess, right?
Surkov, technically it's possible anyway if they want to go to ISimpleDOMNode. However, most likely they are just using text change events or the text interface. I see we fix this and file up any necessary follow-ups.
(In reply to comment #7)
> Surkov, technically it's possible anyway if they want to go to ISimpleDOMNode.
> However, most likely they are just using text change events or the text
> interface. I see we fix this and file up any necessary follow-ups.
> 

Ok, this ability will be disabled by bug 372131 when accessibles for leaf text won't implement text interface.
Comment on attachment 301694 [details] [diff] [review]
Expose one * for each real character in the password


>   PRInt32 startOffset = aStartOffset;
>   PRInt32 endOffset = aEndOffset;
>+  PRBool isPassword = (Role(this) == nsIAccessibleRole::ROLE_PASSWORD_TEXT);

Please add comment here you handle accessibles for elements based on html:input@type="secret" and add XXX section we don't support entirely ARIA secrets usage.
Attachment #301694 - Flags: review?(surkov.alexander) → review+
(In reply to comment #7)
> Surkov, technically it's possible anyway if they want to go to ISimpleDOMNode.
> However, most likely they are just using text change events or the text
> interface. I see we fix this and file up any necessary follow-ups.
> 

In general I didn't mean cases how to cheat here. I just thought since we
provide text interface for leaf text accessibles so AT could announce it.
Version: unspecified → Trunk
Comment on attachment 301694 [details] [diff] [review]
Expose one * for each real character in the password

Drivers: this affects privacy when a user installs a screen reader that uses ATK/AT-SPI on Linux or IAccessible2 on Windows. Screen readers want to do the right thing (not echo the text), but may forget to check the state/role to see if it's a password and thus not echo text. We want to help them to the right thing here.
Attachment #301694 - Flags: approval1.9?
Attachment #301694 - Flags: approval1.9? → approval1.9+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
in-testsuite?
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.