Seeking community feedback: Disallow add-ons to run on secure screens.

[feerrenrut]

Overview

There is currently no way to ensure that add-ons are secure to run. This is especially concerning on secure screens. When config is copied to secure screens, all add-ons are also copied. This presents an elevated security risk to users.

NV Access intends that NVDA should meet the minimum requirements for users when on secure screens, without requiring add-ons.
Examples of secure screens:

• Sign on screen (where you enter your password, not the lock screen)
• UAC prompt

To make identifying secure screens easier, set a unique synth voice, copy it for use on secure screens and experiment.

There may be use-cases that require add-ons on secure screens e.g. NVDA remote. These use-cases can be studied and alternative approaches will be suggested. Other example use-cases are welcomed.

We'll first collect use cases for secure screens, then we'll plan our approach.
This may involve:

• Incorporating add-on functionality into NVDA.
• Exposing new add-on API's, to allow certain add-on functionality on secure screens without 3rd party code running at an elevated privilege level.
• Other approaches to add-on management.
  • Allow selection of add-ons to copy to the system config #6305

Why now?

Add-ons have been allowed to run on secure screens for a long time, why change approach?

The security risks are being taken more seriously. Add-on source code isn't reviewed, and can't be guaranteed to be secure. Every update to an add-on and all dependencies would need to be inspected.
Some users assume that the "official" add-ons are reviewed. This is not the case.
Even if the add-on itself can be trusted, it is very easy for it to introduce an additional attack vector.
E.G. making it possible to open a saveAs/open dialog, or command prompt.

The other motivating factor is ensuring NVDA meets a minimum set of core requirements. Secure screens have a narrow set of requirements for the core to meet.

Use-cases for add-ons on secure screens

Primary use-cases, which may prevent some person from using NVDA without assistance.

• NVDA remote:
  • A remote computer may be configured to lock itself. The user needs a way to connect to it, enter a password, so they can log in.
  • When operating a remote computer with UAC, the user needs a way to read and allow/deny UAC prompts.
• Synth drivers for languages not supported well by core:
  • No examples yet.
• Braille drivers for displays not supported in core, required for deafblind users:
  • No examples yet.
• Proxy support: Particularly if using NVDA remote to access a machine which is behind a proxy.
  • The system proxy settings are not observed by Urllib or socket modules.

Other suggestions

Other suggestions made, which aren't as clear cut. These may require further discussion AFTER we have made a decision on the approach for primary use-cases.

• Kill NVDA: terminate NVDA during a freeze
  • This shouldn't be required. NVDA's watchdog should take care of this. Perhaps improvements are required here.
• Speech History: Repeat last spoken text, useful on the sign on screen when something unusual happens, e.g. Windows installing updates there is only text printed on the screen but no control.

Related issues:

• Closes: Create an add-on manifest key to specify whether an add-on should be available on secure screens #13429
• Allow selection of add-ons to copy to the system config #6305
• Disable Configuration Profiles entry in the NVDA menu on the logon screen (secure desktop) #8521

[feerrenrut]

I'm going to collect responses and add them to description, hiding the original comment (to make it easy to track what has been responded to).

First, I want to highlight the difference between the 'lock screen' and the 'sign on screen'. The first is not a secure screen. The second (where a Windows user enters their password) is. To make identifying secure screens easier, set a unique synth voice, copy it for use on secure screens and experiment.

I'll attempt to respond to all the comments so far, per user.
I'll use a heading level 4 (edit: previously level 3) for each person. My questions for comments will be numbered for ease of reply.

@ruifontes comment

Other add-ons that need to run on secure screens are synths add-ons.

This sounds like a preference rather than a requirement.
1. If your reasoning isn't already captured by other comments, can you please elaborate on why a user MUST have access to these 3rd party synths?

@lukaszgo1 comment

Aside from NVDA Remote There are two main categories of add-on which are necessary on secure screens IMO

Synth drivers - while NVDA has support for some synthesizers out of the box they may not support some languages, or not be understandable for people with various hearing difficulties.
Braille display drivers - there are a lot of braille displays out there, not all have support in core, requiring users to purchase a supported display is unreasonable given their price, and for Deafblind users inability to use braille display their have on secure screens equals not being able to use their computer independently.

I'll add "unsupported languages", these should be added to core.

2. Do you have specific examples of languages not supported well enough for the sign-on screen and UAC prompts out of the box?

I'll add "Braille display drivers", with a note about deafblind users. These should be added to the core, future displays should use BrailleHID.

3. Can you please supply specific examples of braille displays that aren't supported?

CyrilleB79 comment

Kill NVDA: Allows me to terminate NVDA when the user instance of NVDA is totally frozen.

4. This one makes me hesitate, is this something a regular user requires?

It shouldn't be. I understand developers are much more likely to run into strange situations, but I really want to focus on average end users to start with.
I'll add this as a secondary use case, I don't think we should spend time discussing this until we have solutions for primary use cases. See the description for definitions.

Speech History: Allows me to have last spoken text repeated in case I have not been able to hear them; specifically useful on the logon screen in case something unusual happens, e.g. Windows installing updates.

Again, I'll add this to secondary use cases.

5. By 'logon screen', do you mean 'lock screen' (not a secure screen, addons will run), or sign-on screen (where a password is entered)?

Windows Magnifier: Enhances the usage of Windows Magnifier along with NVDA by vocalizing native shortcuts and adding new features to it.

This is too general, please add:

6. Which 'secure screen', and what action on it requires this add-on?
7. For the rest of the suggestions, please be more specific about why they are required (I.E. a user can not get by unassisted without the add-on)

@josephsl comment

If the community believes that add-ons should be used in secure screens, the linked issue should be investigated too.

Yes, this may be an action, I've linked to it in the description. But please stay on topic: specific use-cases that require an add-on on secure screens.

asking add-ons to run on secure screens because people would like to use parts of it.

To be clear, we are after use-cases that aren't about preference, but requirement.

ask add-on components to come to NVDA Core which guarantees full or partial support for secure screen interaction

This may be an action, I have included it as a possible outcome in the description. But we need the concrete use-cases.

@jmdaweb comment

Proxy support may be also helpful on secure screens. For example, when NVDA Remote is configured to connect automatically and the NVDA instance is running behind a proxy.

I'll add a note, however:

8. Why can't the proxy be configured at a system level?

@sukiletxe comment

What about letting the user choose which add-ons to copy?

This potential solution has been added, see issue #6305. On this issue, please focus on required use-cases for now.

@davidacm comment

I use beep keyboard, it’s very useful for me when I'm typing passwords

9. Can you expand on this, is it required (I.E. you would not be able to log in without it)?

If this is a general preference, it sounds simple enough that it should be added to core.

Power status tones, an unofficial add-on developed by me, I use this to listen a sound if laptop is charging or not and I like to know it even if the computer is blocked.

To be clear, the lock screen and sign-on screen are different. Only the sign-on screen is a 'secure screen'. Add-ons would continue to work on the lock screen. I have added notes to the description on how to confirm you're on a secure screen.

@pitermach comment

There are potentially a variety of solutions. Right now, we want to focus on discovering the requirements.
If there is no requirement for general add-on availability on secure screens, we can keep the approach simple.

@davidacm comment

Another solution could be...

We aren't looking for solutions right now.
I think @josephsl has covered some of the concerns with this approach, however, if you'd like to discuss it further please do so either on the mailing list or via GitHub discussions.

[feerrenrut]

As per my last comment I'll respond to all new comments in one go.
I'll use heading level 4 for the name of the person I am responding to (prior comment updated as well), this is less easily confused with the Github comment headings.

@sukiletxe comment

About Kill NVDA, I cannot provide examples but I have needed to use it sometimes, as NVDA was completely irresponsive.

10. You've encountered this on the sign-on screen or during a UAC prompt?
Either way, this would be a serious bug that should be fixed within NVDA.

@Simon818 comment

I do need Bluetooth Audio on some machines,

11. Can you elaborate, why do you need Bluetooth Audio?
12. Without it, what prevents you from signing in (entering your Windows password) or using a UAC prompt?

Mostly though, I like the idea that if I want to run custom code in my NVDA, I can.

This won't change, only in the very specific circumstances.

I think it would be better to focus on ways to allow the average user to do this in a safe and sensible way

The problem is as the add-on developer community grows it becomes impossible to verify that add-ons are safe. This is already true. Add-on source code and dependencies are not reviewed. Even if the available source code was reviewed, there may be malicious binaries included with the add-on.
Given this huge security risk of running code at System level, this issue aims to understand what minimum requirements are unmet by NVDA core.

I don't think it's realistic to trust that core can do everything everyone might want at this point.

This issue should make it clear one way or another. To be clear, our current priority is identifying requirements "must have", rather than preferences "might want". I.E. the user can not proceed without it.

@gregjozk comment

when I worked in Word (heavy and fast typing),

This doesn't sound like something you would be doing on the sign-on screen, or during a UAC prompt.
This situation won't be affected.

so, Kill NVDA was and still is very useful addon, when NVDA freezes.

Yes, NVDA freezing is a serious bug, not recovering automatically is also serious. These situations should be reported and fixed in core.

@jmdaweb comment

Regarding your question about the system proxy...

Thanks for the extra information. I didn't realize you were talking about observing proxy settings from Python rather than configuring them.
I'll add a note that observing the system proxy setting would have to be addressed.
This would generally be applicable to NVDA core, and any other add-ons that require Internet access.

@zersiax comment

The vast majority of times, the secure screen will only be visible for a few seconds at most

This is all it would take to start a new elevated process. The process can then run as the system user, and install whatever services etc. It may replace binaries of the OS or other applications. An extended period of time is not required.

I would think that the addon reviews would catch most nefarious intent

Add-on source code is not reviewed in any official capacity, and may not be reviewed at all.
Attempting to review all add-on code is not effective or scalable.
Add-ons may include binary dependencies which are also unable to be reviewed.

Will mitigating these security risks inconvenience users?

This is what we would like to identify, it is the purpose of this issue.
We intend to weigh up the costs of different approaches.
To do so we must understand the impact.
That said, the primary concern is allowing people to continue to rely on NVDA to have unassisted access to their computers.

@CyrilleB79 comment

But the Kill NVDA add-on allows to kill the running instance of NVDA in the user session in case this instance is frozen and the keyboard is also blocked.

It maybe that we have to adopt all or part of this functionality into NVDA in order to solve this problem. It's noted in the description.

No I do not mean lock screen.

Thanks for the clarification. I have updated the description with this.

The add-on helps me understand if color inversion is active or not, what is the position of the zoomed view in the full screen,

13. Could you give a specific usage on either the sign-on screen, the UAC prompt, or any other secure screen?

@Simon818 comment

Is there a reason there's a sudden focus on trying to make this "scorched earth policy" work when #6305 didn't have priority for a long time?

The motivations are primarily internal (however discussion amongst add-on authors has also increased priority).

• NVDA 2021.3 required several security fixes to prevent access to features while on secure screens. As part of this, a high level audit was completed to assess whether there were other similar unreported security issues. Add-ons running on secure screens was identified. We are unable to ensure an add-on is friendly, and unable to ensure it doesn't expose the user to unnecessary risk. There has additionally been discussion on this within the add-on community.
• Secure screens are very simple, the user-requirements for NVDA are as narrow as possible. Being able to meet these requirements within the core of NVDA is a good outcome for all users.

Understanding what additional requirements exist for NVDA core allows us to make a realistic assessment of the costs associated with various approaches.

In corporate environments, no user should be able to install addons anyway, and at that point it would be perfectly acceptable not to have any at all.

14. This indicates that add-ons are not required, and are a "nice to have", is this your opinion?

I feel as though making this change will result in a constant stream of requests and complaints and workarounds and compromises that really won't make anybody completely happy.

This seems to contradict, if you have specific examples please include them.

[feerrenrut]

As per my last comment
I'll use heading level 4 for the name of the person I am responding to.

@sukiletxe comment

About Kill NVDA, I cannot provide examples but I have needed to use it sometimes, as NVDA was completely irresponsive.

10. You've encountered this on the sign-on screen or during a UAC prompt?

In neither.

Ok. In this case it isn't really relevant to this conversation.
This proposal is only about the sign-on screen and UAC prompts.
Though as already discussed, the functionality of 'kill NVDA' is something NVDA should handle without need for an add-on.

@DrSooom comment

See also: Issue #8521

Thanks, I have added this link to the description.

[CyrilleB79]

Hi Reef

For Windows Magnifier use cases, I do not think it is totally necessary to have it on sign-on screen or UAC one, it's more a nice-to-have for my personal usage: I feel more comfortable to be able to follow visually what NVDA says, but I am able to sign in or to enter my password without any problem. If I encounter a blocking issue for myself or someone else, I will let you know.

Regarding an example of Braille display driver not included in NVDA, maybe MB408SL-driver. I know nothing about it but just read something about it here:

• MB408SL-driver (Braille display driver): not compatible yet (I'm waiting an user report from my community, it's a display distributed mainly in Italy);
  @ABuffEr, maybe you can comment further?

[mikolysz]

A few use cases that come to mind:

1. Drivers for hardware speech synthesizers. I know several people who still use those, and one of their primary reasons is that they work independently of the computers' sound system. If sound suddenly stops working for any reason, hardware synth users want to be able to at least sign in and fix the issue. Some users might also have their headphones plugged into the synth instead of the computer. In their case, signing in with a software synthesizer might be technically possible, but extremely inconvenient.
2. The add-on that makes character echo work, even in secure fields. This is a security risk, but there are users whose typing skills aren't that great, and they tend to hit the wrong keys sometimes. For these users, such an add on is basically required to sign in independently, especially if, for one reason or another, their password needs to be long and complex. Unlike sighted users, blind people can't just look at the keyboard, and braille labels are expensive and hard to come by. For that reason, I think it's essential for a screen reader to let inexperienced users confirm that they're typing in the correct characters, even in these fields.

I'm not sure if it's possible for system administrators to add custom secure screens (thing custom authentication flows, 2FA screens that appear before signing in etc.) If so, we need to allow arbitrary add ons to run, in case some users require an add-on to make such screens accessible.

The fact is that we can never really predict what kinds of addons users might come up with. Whether it's voice control, switch access or something altogether different, if we disallow addons on secure screens, we're potentially limiting the usefulness of all kinds of accommodations addons, and that's something we need to think about.

[lukaszgo1]

Sorry for the late reply:

• As to the Braille displays not supported in core asking users what of these are used seems strange since NV Access has much better visibility to what display drivers are used by usage stats you're collecting. Obviously these are not collected on the secure screens, but we can safely assume that if someone has a display which is supported only via an add-on they may expect, and rightly so, to have it working when signing in. The displays I know about are:
  • The MB408SL-driver mentioned by @CyrilleB79 - integrating it in core would not be feasible as it requires external dll's
  • as part of Native driver for Handy Tech braille displays #7590 we dropped support for some older Handy Tech displays and asked users to use add-on Handy Tech provided - telling users that, no, you cannot do this anymore is simply wrong
  • This does not apply anymore but after NVDA 2019.3 users of Seika displays had to use an add-on for their displays since reviewing and merging a fix which made them work again and added support for additional models took more than a year.
  • There are some- very unofficial - drivers flying around in the community for old Alva displays - it was decided not to merge them in core since they work only on a limited range of Windows versions.
• As to using HID for all future displays while I agree with this on principle if the given display targets mainly desktop machines NVDA is the only screen reader which supports HID which makes its adoption for a display vendor way less attractive than it should be.
• With regard to external synthesizer drivers while I cannot point out specific examples of unsupported languages (I once again urge you to use the stats you're collecting) a lot of users with hearing difficulties tent to use Eloquence since apparently this is only synthesizer they could understand. It is obviously impossible for me, or for that matter for anyone else who isn't in their specific condition, to asses to what extend this is a preference rather than a necessity but we are a program for people with disabilities after all, and if someone tells us that they want to work comfortably we should do whatever it takes to help them achieve that goal.
• Another add-on which has to work on secure screens is Unicorn DVC - without it it is impossible to log into the machine accessed via Remote Desktop / Citrix solutions. Alternatively we can of course consider implementing add support for sending speech over remote desktop protocol channels #3564 in core.
• Add-on for Windows Magnifier - I don't have enough usable vision to use it but tighter integration with Magnifier has been mentioned as one of the possible projects for Google Summer of Code here so integrating parts or all of it into core seems a reasonable request
• Kill NVDA - I don't think it is as necessary as people tent to imply. An alternative approach which works for me is to create a second user account, and when NVDA is frozen badly enough I just log into it from the CTRL+ALT+Del screen and kill NVDA that way using task manager.
• Bluetooth audio may be necessary for some people even on the login screen since a lot of sound cards tent to cut beginnings of every speech utterance and this add-on is the only working remedy - it certainly was for me until I finally found some unofficial sound driver for my secondary machine and managed to convince Windows Update not to replace it every two days.

I also don't think we can draw any definitive conclusions from the discussion here. Most users, especially outside English speaking countries would never comment or even look at this issue and there is a high chance they have some specific need we haven't considered. In fact if we know that synthesizers and braille display drivers can be distributed as an add-ons we should not look for a specific examples as we cannot possibly find all of them. What I'm saying is that if it is decided that add-ons on secure screens are going to be disallowed we should have a plan for an unexpected cases as most of them would be reported by ordinary users after and not before the release.

[mikolysz]

Kill NVDA - I don't think it is as necessary as people tent to imply. An alternative approach which works for me is to create a second user account, and when NVDA is frozen badly enough I just log into it from the CTRL+ALT+Del screen and kill NVDA that way using task manager.

This approach assumes you have administrative access to your machine, which may not always be the case. Integrating the functionality of kill NVDA into core seems reasonable, though.

[davidacm]

Why not just allow users to choose what add-ons they want to use in secure screens?

Like an add-on manager that let to users to select and install / uninstall add-ons in secure screens. This can be implemented in the add-ons manager view. And obviously, that will require user UAC confirmation each time the users copy or remove add-ons from the NVDA's system configuration, and a confirmation dialog warning the user about risks of doing that action.
Currently, I don't use the "use currently settings in secure screens" because I don't want all add-ons to be copied to secure screens. I copy settings manually, and I copy just the add-ons that I need for my personal case. But most of users don't know how to do that.

We can't assume all the needs of all users, we are not gods that can foresee all users situations and needs.

Talking about security risks, even a ill-intentioned braille driver can damage the system or compromise security. So, from that point of view, 0 add-ons should be copied to the system configuration.

I see here some complex solutions that requires advanced knowledge from users. We need to think as common users, not developer users.