nvaccess
Seeking community feedback: Disallow add-ons to run on secure screens.
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.
- https://github.com/nvaccess/nvda/issues/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: https://github.com/nvaccess/nvda/issues/13429
- https://github.com/nvaccess/nvda/issues/6305
- https://github.com/nvaccess/nvda/issues/8521
(Issue #13686)
On Wed, May 11, 2022, 4:21 AM Reef Turner @.***> wrote:
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 prevents an elevated security risk to users.
NV Access intends that NVDA should be meet the minimum requirements for users when on secure screens, without requiring add-ons. Examples of secure screens:
- Sign on screen
- UAC prompt
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. Related issues:
Closes: #13429 https://github.com/nvaccess/nvda/issues/13429
— Reply to this email directly, views it on GitHu https://github.com/nvaccess/nvda/issues/13686b
, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXT2QULQIQQ45UWWNUME6OTVJOCZPANCNFSM5VUNFQOQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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.
Looking at my personal use, I have three add-ons in the systemConfig that are not speech or braille drivers:
- Kill NVDA: Allows me to terminate NVDA when the user instance of NVDA is totally frozen.
- 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.
- Windows Magnifier: Enhances the usage of Windows Magnifier along with NVDA by vocalizing native shortcuts and adding new features to it.
IMO, Speech History could be integrated in NVDA (cf. #625); for the record, the feature has been available in Jaws for at least a decade. Kill NVDA would also fit in core even if it is an advanced feature. Windows Magnifier is the only add-on that does not deserve to be included in NVDA's core.
Looking at the community webpage here are the add-on that may have an interest on secure screens:
- PC Keyboard Braille Input
- NVDA Unmute
- Numpad Nav Mode
- Focus Highlight: this add-on is more complete than NVDA's core Focus Highlight feature
- Enhanced Touch Gestures
Also the following ones may be considered although they seem of a least importance:
-
Report Passwords (unless it is not accepted for security reasons); for now it is totally disabled on secure screens.
-
Input lock (unless not accepted for security reasons)
-
BrailleExtender (maybe some features)
-
sayCurrentKeyboardLanguage
-
Object Location Tones
Well, personally I don't need any addon on security screen, so I want to have a mechanism for nvda to not copy addon to the secure screen.
Hi,
A few things to consider:
- For several years there has been an attempt to let NVDA ask users if they wanted add-ons to be copied or not (#6305). If the community believes that add-ons should be used in secure screens, the linked issue should be investigated too.
- More importantly, I can see some folks asking add-ons to run on secure screens because people would like to use parts of it; or for that matter, ask add-on components to come to NVDA Core which guarantees full or partial support for secure screen interaction (I think Enhanced Touch Gestures was mentioned as it contains touchscreen commands). Supposing that folks would like some global plugins to be useful in secure screens such as Speech History, then the follow-up step would be componentizing add-ons i.e. making sure add-on parts are separate enough to be turned into NVDA Core pull requests (this also means interference between add-ons is minimized as add-ons can patch NVDA Core functionality for various reasons).
While both items I outlined are important concerns, I consider the second item to be more relevant to this issue. However, to keep this issue on topic, I will not go into specifics of how to separate add-on code into parts as it is something to be taken care of in the add-ons community.
Thanks.
Hi, 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. Regards.
What about letting the user choose which add-ons to copy? If not, who will decide which add-ons to allow based on what criteria?
That said, I don't have any add-ons I'd want on secure screens besides remote and Kill NVDA.
Hi.
Added to the mentioned add-ons, I use beep keyboard, it’s very useful for me when I'm typing passwords. 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. I know, NVDA speaks it, but you know, we usually don't pay attention to the synth if we are doing other things.
So, considering that above, I think the best way is to allow the user to select what add-ons he/she wants to be copied in the secure screens. I usually do it manually, but not all users have the knowledge to know how to do this.
Just want to agree with what others said Re: give me a choice what to copy and enable. I'm a bit concerned that what you're proposing here is just not allowing any ad-on on secure screens. While the idea of that is sound, I don't think going with the approach to block everything and give no user choice is the right one.
If you want to make NVDA appeal better to more secure environments and less easy to compromise for less experienced users, start with having no ad-ons copied to secure screens or just lower risk ones like Synth Drivers, with some checkbox saying you understand the risks of allowing ad-ons on secure screens when you choose to copy them.
Another solution could be... To have a way to validate add-on authenticity via a hash. The hash list could be integrated on the NVDA's core, or preferably, in a online server.
Just verified add-ons could be copied to the system. This aproach is very restrictive for the users. But then, an option in advanced settings can be iplemented. If the user check this option, then the user can bypass the restriction. This option will be disabled each time the user install a NVDA copy from a portable version.
Hi, as in have a database of trusted add-ons and their hashes, a list of hashes add-ons should check for whatever reason, or something else? What if a “trojan horse” add-on passes hash checks? What if a human or a module tampers with hash list?
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 https://github.com/nvaccess/nvda/issues/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.
About Kill NVDA, I cannot provide examples but I have needed to use it sometimes, as NVDA was completely irresponsive.
I don't nate this idea, and there is some logic to it, but I'm not a huge fan of it compared to other approaches such as #6305. Personally, I don't need my secure screens to speak using a different synth, but I like it when they do. I do need Bluetooth Audio on some machines, and NVDA remote on all machines. I've never needed Kill NVDA; restarting it has always worked for me, but some people aparently do. Mostly though, I like the idea that if I want to run custom code in my NVDA, I can. I think it would be better to focus on ways to allow the average user to do this in a safe and sensible way (such as #6305) rather than going from all to nothing. I don't think it's realistic to trust that core can do everything everyone might want at this point.
about Kill NVDA:
when I worked in Word (heavy and fast typing), NVDA often froze. If I didn't want to luse my work, I had to use Kill NVDA via (ctrl+alt+delete) "launching task manager". work around was to instruct word to save work every minute. so, Kill NVDA was and still is very useful addon, when NVDA freezes. here is my point, why should be this addon allowed on secure screens or its functionality be included in NVDA's core.
Hi Reef, Regarding your question about the system proxy, Python native proxy support is far from being enough. Urllib module added support for basic proxy autentication in Python 3, and already supported http, https and ftp proxies in Python 2. Proxy can be configured via environment variables (HTTP_PROXY, HTTPS_PROXY, ...) and/or registry settings (the only situation where system proxy is taken into account). In a lower level via the socket module, proxy servers aren't supported at all by default. The proxy support add-on makes use of the PySocks module, and patches urllib and/or socket modules depending on the user needs. This is the only way to make NVDA Remote connect via SOCKS or HTTP proxies. I invite you to take a look to the add-on source code to understand better how it works. Regards.
To me this all feels a bit hasty. Yes, NVDA addons could in theory do anything they like. They are written in Python, and Python does allow for that kind of power. This is why addons are vetted, reviewed etc. Yes, it would in theory be possible for an addon author to, deliberately or not, expose a security risk for the user. But we do need to do just a tiny bit of risk assessment here before employing what feels to me like a bit of a Scorched Earth policy.
-
Is the scenario of remote code execution as a direct result of addons running on secure screens likely? No. The vast majority of times, the secure screen will only be visible for a few seconds at most, e.g. a UAC prompt, making the window far too small for , say, a reverse shell to be of any use. i really don't think there'd be enough time to escalate to a proper shell or do much of anything else.
-
Is arbitrary local code execution likely? Possibly. I would think that the addon reviews would catch most nefarious intent, but I guess it's always possible something could slip through the cracks. Either way, users are going to download what they are going to download in the form of cracks, illegal addons etc. which could do all sorts of stuff on the user's machine, secure screen or otherwise.
-
Will mitigating these security risks inconvenience users? I think that, looking at this thread, we can safely say that yes, users have all sorts of reasons why they might want to run addons on secure screens and imho, just waving those off as "not actually required, will fix later" is somewhat user-hostile. Merging functionality into core, creating exemptions for addons etc. feel like a process that would take at least some amount of time, whereas preventing addons on secure screens should be a relatively simple thing to do. It feels to me like what is being intended here is to do the latter first, and then work on the former, which means people who do have use cases for this will not be able to use the latest NVDA for those use cases until all is said and done.
I'd say making the addons that get copied to secure screens is a great middle of the road solution here. That way, users who need certain addons can use them, and addons that shouldn't be on those screens get held back. Doing any more here feels like tilting the balance too far towards the wrong side in the security vs usability debate.
Here are the feedbacks on the add-ons I have in my systemConfig folder:
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?
I agree that theoretically, a regular user should expect NVDA not to freeze at all, so it should definitely not be a primary use case. And when NVDA freezes, pressing control+alt+N should restart NVDA in any case. 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. Technically, it is not an add-on that targets the instance of NVDA running on secure screens. But to be able to kill an NVDA instance in a user session (without restarting the computer or the session), the add-on takes advantage of the 2 following facts:
- Even if the keyboard input is frozen/blocked, ctrl+alt+delete still operates and allows to open a secure screen with NVDA
- The instance of NVDA running on secure screens has system privileges, allowing to kill a process in a user session. In practice, there are various unresolved NVDA frezzes and some of them also have the keyboard blocked (#13432, #10247, #6463).
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)?
No I do not mean lock screen. I mean sign on screen (the password one) as well as other secure screens, e.g. in case of updates, there is only text printed on the screen but no control I think.
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 my personal usage, it's just comfort enhancements on secure screens since I can do everything with the screen turned off. My primary access to information is speech from far, then visual and lastly braille. 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, etc. Useful in case of low and central vision, but nothing mandatory for myself. If other low sighted persons have a different experience, I'll let them 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? Nobody can disagree that disabling addons altogether would create a more secure NVDA, but why does that suddenly matter? 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. On home computers, it's the user's responsibility to keep their own machine secure, whether they install an addon or a service or anything else that might possibly open them up to security threats. We've also seen that NVDA core isn't exempt from these kinds of exploits. And there is such a staggering number of NVDA users around the world that 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. I guess what I'm saying is ... I would take this more seriously if something like #6305 had been adopted first and there was reason to believe it still wasn't enough.
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.
About Kill NVDA, I cannot provide examples but I have needed to use it sometimes, as NVDA was completely irresponsive.
- You've encountered this on the sign-on screen or during a UAC prompt?
In neither. Kill NVDA kills the main instance of NVDA, and then NVDA restarts. So it works like this: I am doing something, NVDA freezes. CTRL+Alt+N doesn't work (maybe it's too slow), Ctrl+Windows+Enter neither. So, I press Ctrl+Alt+Delete. I use the Kill NVDA function, which kills the main NVDA. I press escape, and NVDA restarts. This is, exactly, the situation where Kill NVDA should be used, and the way to use it too, as per its docs.
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.
- 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.
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?
A few use cases that come to mind:
- 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.
- 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.
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 #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 #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.
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.
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.