Add a decider extension point to suppress key echo

[nvdaes]

Is your feature request related to a problem? Please describe.

Some users may want to listen typed characters in protected fields, for example to be sure that they are typing passwords correctly.
Some add-ons were created for this, and they patch the isTypingProtected function.

Describe the solution you'd like

Add a decider extension point replacing the current isTypingProtected function, available in the api module.

Describe alternatives you've considered

An option to speak characters in protected fields can be included in Keyboard settings, in NVDA's core. This would replace the reportPassword add-on, available in the store.

Additional context

This was discussed years ago in a spanish mailing list, and a teacher mentioned that this may be useful for students.

[Adriani90]

Imo this should definitely remain an addon due to potential security risks which might make NVDA a no go for corporate environments. such a setting will never be accepted by sysadmins. Cc: @gerald-hartig

[CyrilleB79]

From what I understand, the feature would remain in an add-on. The scope of this request is that the add-on coud use a decider extension point instead of monkey patching a core function.

[nvdaes]

Hello. As Cyrille mentioned, my first purpose with this issue is to use a decider in the reportPassword add-on insteas of patching a function.
Anyway, this may be implemented in the core, for example in keyboard or advanced settings.
Sometimes to be informed about the typed password may be considered more secure than typing a wrong password, for example if the screen curtain is active and we use headphones.

[Adriani90]

Imo having this setting in core is a security vulnerability, especially for beginners who might enable it accidentally. For sysadmins this would be a no go, especially when they need to provide remote assistance and the user hears the password when the sysadmin enters it.I agree an extension point might be helpful, but me at least vote against having such a setting in core.Von meinem iPhone gesendetAm 29.11.2024 um 14:33 schrieb Noelia Ruiz Martínez ***@***.***>: Hello. As Cyrille mentioned, my first purpose with this issue is to use a decider in the reportPassword add-on insteas of patching a function. Anyway, this may be implemented in the core, for example in keyboard or advanced settings. Sometimes to be informed about the typed password may be considered more secure than typing a wrong password, for example if the screen curtain is active and we use headphones. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[seanbudd]

Our preference is incorporating the setting directly, and binding a key command to it, rather than the extension point. If this setting gets incorporate is there still a usecase for the extension point?

[nvdaes]

@seanbudd , I think that if we incorporate this in a setting, we don't need an extension point. I'll create a PR including this in keyboard settings and assigning it the NVDA+x command. X may mean something hiden, like in equations, and NVDA+p is used for punctuation.

[Adriani90]

@seanbudd please reconsider this, given my comment above. I think we need more community feedback on this, since e.g. Narator does not provide such a setting due to obvious reasons. System admins will definitely take this into account when deciding which software is allowed.

cc: @gerald-hartig, @jcsteh

I will definitely send this issue to all community groups to start a discussion on regarding having such a setting in core.

[nvdaes]

@Adriani90 , smart phones have this option, accessible with screen readers. What I mean is that your proposal is valid, of course, but not obvious.

[CyrilleB79]

I am not against optionally echoing typing in protected fields.

Though, I vote against assigning a default gesture, especially an easy one. With a default gesture, there is too much risk that someone inadvertently enable the feature by mistake.

[nvdaes]

@CyrilleB79 , your explanation about a default gesture makes sense. I'll leave the command unassigned.

[davidacm]

I don't agree with implementing this feature in the core. It might be useful in certain scenarios, but I'm worried about what IT admins might think.
@Adriani90 explained it very well in his email, which is why I'm here.
For example, a support technician who must perform operations on my computer remotely, could be exposed if I have the possibility of listening to the access passwords.
It's the point that worries me the most, if there is any idea to solve it, then I might agree to integrate this feature.
@Adriani90 brought up other valid points, but in my opinion, NVDA in corporate environments is the most important point to address before implementing this feature.

How do other screen readers handle this?
I mean, Narrator, JAWS, Voice Over for Mac...

[nvdaes]

I don't see the difference, in terms of security, of having this setting in the core or in an add-on.
Anyway, for security, it would be better to add this to advanced settings, that aren't available when NVDA is run in secure mode.

[nvdaes]

Since this is being discussed on NVDA groups, this is a summary of my replies:

• After Cyrille's reasoning, my intention is to leave the command to change this setting unassigned, to prevent accidental changes if the keystroke is activated unintentionally.
• As mentioned in the issue, smartphones provide this feature with screen readers.
• I also mentioned that sometimes may not be secure to type wrong passwords.
• About remote control, if the add-on is active, this option can be activated too.
• When we grant access to a computer to be controlled, there is risk to run software and change settings, even someone may install the reportPasswords add-on.
• I'm happy maintaining this add-on if needed, but if this is included in NVDA's core, NV Access will have more control of this setting.
• If NVDA's debug or input/output log is active, and someone is controlling our computer, we have the risk of show our keystrokes if we type a password.
• In advanced settings, there is an option to speak passwords on Window consoles.
• • I'll add this to advanced settings, so that this won't be available from secure mode.

[CyrilleB79]

Adding the option in advanced settings is useless. Either we consider the option secure enough and we add it in widely accessible settings. Or we consider that the option is not secure enough in all cases and we keep it as an add-on.

This option, if made available, should not be available for advanced users only or upon request of a helper person. Thus it has not its place in advanced settings.

Also, regarding security, if the option is in advanced settings or not has no impact: any script or program having write access to nvda.ini can easily change the value of the option.

[zstanecic]

Hi, as i don't see the real benefit of this function, and see it as a fancy gadget, because even jaws is not implementing it, for the security reasons i am against it being in the NVDA core, because of the corporate environments. It admin can then be against NVDA in the corporate environment because of this.

[davidacm]

Hi, I pasting my comment here as @seanbudd suggested.

I just had an idea for echoing when typing passwords. I don't know if it has been discussed previously, I don't want to read the entire message thread...

Initially, it could be implemented in an add-on for testing.

A custom dialog could be implemented where the user can type the password, and when they press OK, NVDA will type the password in the focused field.

The flow would be like this:

1. The user finds a password field.
2. The user presses a command, which opens an NVDA dialog with an edit field, an OK and cancel button.
3. The user writes the password, it is visible and audible.
4. The user presses enter or presses OK.
5. The dialog closes, and the password is typed in the password field.

Optionally, the user can press escape and cancel the dialog.

This way braille users will also be able to know what they type in the password field, so it's even better.
The only security risk I can think of is someone viewing the password. Perhaps could make the edit box very small, or a custom implementation of an edit field, but the latter would be much more complex. Especially if it's intended to be compatible with braille displays.
I've made some personal plugins that write text strings into edit boxes without going to the clipboard. I find no technical limitations to this description of functionality.
I think I could make a add-on that does something like described above.
But I don't feel like it's as essential as other features, so I'm leaving it as an idea in case someone else would like to implement it.
If there are enough requests, I will reconsider my decision to developt it.
I know that typing passwords can be tedious, especially in some languages and keyboards that we don't know very well. But security is also important.
This would involve an extra step, but allows the user to decide when to use the feature or not.

I'll also comment on the existing add-on to speak in the password fields.

I think it would not be necessary to eliminate it. The general concern, at least on my side, is in corporate environments. Administrators can control which add-ons will be installed. Furthermore, whoever wants to use the add-on can always find it in other sources.

But I recommend considering my idea as a possible solution, tell me your comments and opinions on it.

[nvdaes]

@davidacm , inspired by your idea, I have another one. I thought that your proposal has the disadvantage of showing passwords, even with small characters, but we aren't sure if they can be seen or not.
Then, I have thought that an input password, for example in HTML, can be created with a checkbox to show or hide it, optionally. Then, when pressing OK the password would be stored in a variable, and with a keystroke, using brailleInput.sendChars, it may be writen in the password field without using the keyboard.
I'm not comfortable maintaining the reportPasswords add-on after this discussion, and this may be used if someone needs it.

[nvdaes]

Also, with this proposal options may be added to listen or not, and displaying in braille or not, the ped password. But, since it would be part of NVDA, it wouldn't affect to remote connections since it should be activated by a dedicated keystroke or a menu option in NVDA.
These are my ideas for now.

[Adriani90]

Thanks for continuing this valuable discussion.I think storing the password might be risky because there could be cases where an user enters a password in the HTML virtual window and might do other things before entering it in the actual password field. So as long as the password is stored the user is exposed to hacking, unless there is a method to encrypt the stored password securely until it is entered in the actual password field.Imo a separate dialog wouldn‘t work, because NVDA doesn‘t show dialogs on Windows secure screens or at Windows login promt. Or am I wrong?So is it not possible to show a similar field like the speech viewer next to the password field when the setting is enabled?It would just show what NVDA is speaking when typing the password.Von meinem iPhone gesendetAm 09.12.2024 um 06:14 schrieb Noelia Ruiz Martínez ***@***.***>: @davidacm , inspired by your idea, I have another one. I thought that your proposal has the disadvantage of showing passwords, even with small characters, but we aren't sure if they can be seen or not. Then, I have thought that an input password, for example in HTML, can be created with a checkbox to show or hide it, optionally. Then, when pressing OK the password would be stored in a variable, and with a keystroke, using brailleInput.sendChars, it may be writen in the password field without using the keyboard. I'm not comfortable maintaining the reportPasswords add-on after this discussion, and this may be used if someone needs it. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[nvdaes]

I think that the password can be stored in an NVDA variable before entering on a secure screen, and I don't see an easy way to show this variable unless the Python console is used.
For reference, we may use this:

https://docs.wxpython.org/wx.TextEntryDialog.html
@davidacm , if you want to create an add-on, I'll remove reportPasswords from the store so people is not confused with two similar add-ons.

[Adriani90]

But how does the speech viewer work then? Does it currently store the speech output in any variable?Von meinem iPhone gesendetAm 09.12.2024 um 06:49 schrieb Noelia Ruiz Martínez ***@***.***>: I think that the password can be stored in an NVDA variable before entering on a secure screen, and I don't see an easy way to show this variable unless the Python console is used. For reference, we may use this: https://docs.wxpython.org/wx.TextEntryDialog.html @davidacm , if you want to create an add-on, I'll remove reportPasswords from the store so people is not confused with two similar add-ons. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[davidacm]

@Adriani90, NVDA can display dialogs on secure screens. At least, the NVDA native ones. I don't know if an add-on could... It used to work in add-ons I think, but I don't know if something has changed.

It means that at least if implemented in the core, a specific dialog for passwords is possible.
If it were not possible in an add-on, anyway I would see it more as a test add-on, to analyze what users think about it.

@nvdaes, I don't understand the idea of HTML very well, is it about how to design the dialog to enter the password?
I've never tried to create an HTML interface with forms in an NVDA add-on. But if that helps to be able to better customize the password input method, then it might work.
Although I don't like the idea of saving the password in a variable until the user decides to enter it in a password field. What would happen if the user has different passwords for other apps... A fairly typical case. I'm afraid I haven't understood correctly the idea.

[nvdaes]

@davidacm , I thought about HTML since I didn't know the exact way to create passwords with WX, then I thought in using JavaScript in some way. I use JavaScript in the readFeeds add-on to add ability to convert feeds into HTML, with ability to copy info to clipboard.
I have also thought about a passwordManager add-on to manage several passwords, and of course, if a unique variable is used, it would be for a field and then it can be removed, after characters are sent for example with brailleInput.sendChars. The advantage of a dialog would be that passwords could be pasted there, and then writen in a password field where sometimes control+v doesn't work.
Definitely I prefer to remove the reportPasswords add-on to be more consequent, at least from the store, if NV Access don't consider appropriate to add an extension point.
Other add-ons with features not included are different since they don't deal with security issues, and I think that not adding an extension point is a way to reject this implicitly. I agree with @michaelDCurran comment, so let's remove it. If I can help you testing a new add-on or whatever, let me know. I have a braille display in case this is useful if you don't have one.

[tspivey]

The arguments I've seen against this feature aren't very compelling.

Someone remotely controlling my computer could type their password into it, and I would be able to hear it.
This is bad security practice. Once you type your password into my computer, you no longer have control over it.
You have no idea what software is running on my computer to capture the password.

IT administrators might not want this feature to exist.
If this is really a concern, add a registry key to disable it. This isn't currently being done for anything else.

The advantages outweigh the downsides:

1. People who are not very comfortable with their keyboard can hear their password as it's being typed.
2. People who are learning a new keyboard layout can hear their password as it's being typed.
3. People who are providing tech support can hear passwords as they are being typed, if wanted.
   That sounds like a security issue, but it highly depends on the situation.
   If you're providing tech support to a friend or family member who trusts you, it might not matter if you can hear their password at that point, it matters that they are typing it correctly, and in the place it needs to be typed without extra steps.

This is a clear accessibility improvement for people who need it.

You can argue against a lot in the name of security. In the case of the Report Passwords addon, I simply don't have to install it.
If it's in core, I don't have to turn it on.
With the addon, it's optional. You don't have to install it if you don't want it, so there's no possibility of your password being exposed without your knowledge.

[CyrilleB79]

Maybe I should have asked before, but:
Does NVDA intercept remote keystrokes in case of remote assistance? I mean, has someone real-life experience on this?

I seem to recall that during a remote assistance on my computer, remote keystrokes did not appear in NVDA's log (debug level). I do not remember very well so just would like to be sure.

I hope that NV Access (@gerald-hartig or @seanbudd) continue to follow this discussion and think about it. There has been a quite strong push of the community to be careful with this feature; and I am not totally sure if it is really justified.
I feel it's NV Access role to confirm or not if people's fears are really justified or not and communicate consequently.

[nvdaes]

@CyrilleB79 and others: what if NVDA, when the speak password options is active and the focus is protected (i.e., when a password field is focused) opens a message box to be accepted by the user? If the user press the cancel or No button, focus should be protected again.
A tooltip maybe good, but a message box that can be accepted or cancelled is more prominent, also for blind users.
For me David solution creating a dedicated dialog is good too. My proposal is that any solution is included in the core.
And, if a dedicated dialog to enter the password is not accepted for the core, anyway I would use an add-on with password manager capabilities if someone creates it.

[CyrilleB79]

For all, I copy here a part of my message sent on the add-ons mailing list:

I'd like to express here my opinion on the security of the add-on and/or the feature proposal:

1. The fact that the feature allows to have typing reported loudly is not a security problem. Let's look at bank identification methods, and I guess banks care about security... They usually use some sort of virtual keyboard. If you are blind you can have a vocal feedback to hear which virtual key is selected and even which is typed. There is a warning to be careful but at the end, it's your responsibility to check that the sound will not be heard by anyone else, and also to use screen curtain if needed. The same way, sighted people click on virtual keys to enter their password code; it's their responsibility to check that nobody is looking behind their shoulders. And all these systems are compliant with GDPR.

2. In the case of remote assistance, the problem, if confirmed in real life, is that the remote assistant may type their password but have no indication that what is typed may be heard on the local computer. Why have you never seen someone entering their bank code remotely on a virtual keyboard? Because it's visually obvious that someone behind the local computer will be able to see or hear the password.

Thus, only case 2 should be fixed in report password feature so that the feature be compliant with security standards. David's proposal is a solution. Another option would be to improve report password add-on so that:

• when the cursor is in a protected field, some sort of tooltype/notifications appears close to the password field, e.g. just below, indicating "Warning: typing echo is active in this field" or something similar. For example, I think that there are similar notifications when caps lock is on in Windows logon password field.
• optionally: the feature is not always active but should be enabled on demand.

If Noelia you do not want to maintain report password anymore, I really hope that the add-on will be taken over by someone else and finally that the feature will find its path to NVDA's core. The need of the feature has been acknowledged by Mick, only the current implementation proposal has been declined due to security issue.

In order not to discourage people imagining solutions, @gerald-hartig could you confirm that NV Access would agree to accept a solution provided both sighted and blind people are correctly warned when echo typing is enabled in protected fields? Thanks.

[Adriani90]

@nvdaes thanks for your great thoughts in this regards. You wrote:

what if NVDA, when the speak password options is active and the focus is protected (i.e., when a password field is focused) opens a message box to be accepted by the user? If the user press the cancel or No button, focus should be protected again.
A tooltip maybe good, but a message box that can be accepted or cancelled is more prominent, also for blind users.

I love this idea actually because it makes clear for both sides that the password will be hearable. A dialog might be annoying though because a user would have to confirm it every time when password field is encountered and this happens very often.
I still think a small speech viewer field next to the password field should give sighted people enough comfort to notice that the password field is unmasked for the blind person and for the sighted person it is the speech viewer field that shows the typed characters so the person can stop typing after he or she sees that the characters are visible.

@CyrilleB79
The warning is what makes this feature GDPR compliant for the NVDA user, and as long as the warning or the behavior is prominent enough and you can decide whether you want it or not, then you are compliant. The problem with the warning in this case is that a sighted person might not know what typing echo means. So the most prominent way to show that this feature is enabled is to see what it really does. And there is where the GDPR problem starts.

1. The Windows audio driver which routes audio of screen reader in software such as Zoom, Webex etc. and the blind person might not know about it. This part needs to be really well documented or fixed in the audio drivers on Windows.
2. The sighted person in a remote connection might not know that the blind person uses a screen reader, so they clearly need a well visible version of this feature so they can react as fast as possible.

I am working in a non governamental bank and I know quite good what GDPR means and how data privacy and subjective security are tackled.

In case of remote assistance, yes this is a real live example, and that's why I brought this point in the advisory group. We for example have many remote assistance cases, bot internally and externally. and when we want to see a specific beavior in an account or so, then we request the person to enter the password, identify via his or her second device through 2 factor autentification etc.
Still if I wanted, I could hear the password of that person with NVDA speak password addon without the person knowing that I am using NVDA at all.
Ofcourse there are other hacky ways to do this, but NVDA should never become a software that provides such a door to abusive behavior or something like that.

[michaelDCurran]

To be clear, although I did say that I believe it is valid to say that a sighted person has an advantage over a blind beginner user as they can see the keyboard as they type their password, I did not necessarily say that I truly believed that NVDA should actually have this feature. True that there are some proposed solutions here that seem to mitigate the security worries, But they all require some kind of implementation, and therefore the burden of actually maintaining these solutions. I think there are many more higher priority issues that would have a much larger impact that we could be spending our time on as a community right now frankly.

[gerald-hartig]

@CyrilleB79 to answer your question, in light of the enthusiasm (bordering on, shall we say, passion?) for this issue, I want to give a very cautious, qualified, tentative answer.

Nobody wants to feel like they’re playing digital pin-the-tail-on-the-donkey when they're entering a password, so if the community can suggest a secure way to address this use case in a way that the benefit justifies the effort, yes we'll consider it. But talking about warnings, tooltips, dialog boxes – oh my! It seems we're rapidly approaching a point where entering a password will require the signing of a legally binding document in triplicate handled by an entire library of code.

I'd like to amplify @michaelDCurran's comment above. Maybe we could redirect some of this creative energy towards those aforementioned higher priority issues? Just a thought. https://github.com/nvaccess/nvda/issues?q=is%3Aissue+is%3Aopen+label%3Ap1%2Cp2