Closed
Bug 415944
Opened 17 years ago
Closed 17 years ago
Don't expose password text through A11y text interfaces
Categories
(Core :: Disability Access APIs, defect, P1)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Keywords: access, privacy)
Attachments
(1 file)
(deleted),
patch
|
surkov
:
review+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
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?
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Assignee | ||
Comment 1•17 years ago
|
||
Attachment #301694 -
Flags: review?(surkov.alexander)
Comment 2•17 years ago
|
||
Comment on attachment 301694 [details] [diff] [review]
Expose one * for each real character in the password
What about aria_secret support?
Comment 3•17 years ago
|
||
(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?
Assignee | ||
Comment 4•17 years ago
|
||
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.
Assignee | ||
Comment 5•17 years ago
|
||
Hmm. Thinking about it more. I don't think they should allow an ARIA password field at all.
Comment 6•17 years ago
|
||
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?
Assignee | ||
Comment 7•17 years ago
|
||
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.
Comment 8•17 years ago
|
||
(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 9•17 years ago
|
||
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+
Comment 10•17 years ago
|
||
(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.
Updated•17 years ago
|
Version: unspecified → Trunk
Assignee | ||
Comment 11•17 years ago
|
||
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?
Updated•17 years ago
|
Attachment #301694 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•