Allow selection of add-ons to copy to the system config

[LeonarddeR]

This idea has originally been posted by @derekriemer in this NVDA-devel thread

We should let the user pick what add-ons they want to choose on the
logon screen, I.E. if I want Vocalizer, and have that, but don't want to
copy NVDA remote.

I propose the following procedure:

1. Go to general settings
2. Press "Use currently saved settings on the logon and other secure screens (requires administrator privileges)"
3. When pressed, show a new modal dialog with the following controls:
   • A list with enabled add-ons, which can be either checked or unchecked. It makes no sense to show disabled add-ons in this list
   • When one or more add-ons are marked for copying, show a checkbox, reading "I understand that copying add-ons to the system profile could be a security risk, and I still wish to copy them"
   • Ok and Cancel buttons
4. When pressing OK, copy the user settings to the system config, including only the add-ons marked for copying.

[derekriemer]

I would suggest making all add-ons disabled by default, to send a signal.

[LeonarddeR]

@feerrenrut: Mind assigning a priority to this? Also, I'd like to know your opinion about what wx control to use. I don't think there's already a list control which allows checking/unchecking of items, but such a control might be an interesting approach for the add-ons manager as well.

[derekriemer]

Also, this would be useful for two other places. Document formatting, and the create portable copy thing so users could choose what to copy.

…

On Mon, Jan 30, 2017 at 10:03 AM, Leonard de Ruijter < ***@***.***> wrote: @feerrenrut <https://github.com/feerrenrut>: Mind assigning a priority to this? Also, I'd like to know your opinion about what wx control to use. I don't think there's already a list control which allows checking/unchecking of items, but such a control might be an interesting approach for the add-ons manager as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6305 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGiveOscO4Cdn3pz59EIXR6OH7Q_3c6ks5rXhftgaJpZM4Jtv8n> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[josephsl]

Hi, wx.CheckListBox is there, but I remember @jcsteh saying something about it. Also, I can see this being applicable for #3208 when users will select which add-ons to update, and I can use a more accessible version of wx.CheckListBox in one of my add-ons.

[feerrenrut]

I'll set this to priority 3. However I think it would be beneficial to tidy up the description of this issue and expand on the use-case. Who this benefits, how it benefits them, and what is the minimal requirement to achieve this.

[LeonarddeR]

Just closed duplicate #4997, which was somewhat broader in scope and also mentions settings, but this issue contains more discussion. I think deciding what settings should be copied is a different issue from add-ons, and that can be covered by #2226.

[josephsl]

Hi,

Follow-up: now that basic infrastructure is in place (checkable list), I think it would be great to let a newbie work on this. I hope this method would not only teach this person the ins and outs of pull requests in NVDA community, but also to serve as a vehicle for attracting new talents (especially college students who wants to learn how to serve people with disabilities through programming skills). There are several issues that could qualify for mentoring, but since this one is one of the top requests, I propose using this one as a pilot.

Thanks.

[LeonarddeR]

Reef is currently working on #8006. I'd like to suggest having that finished first.

[josephsl]

Hi,

Update: #8006 is done, but in order to give room for add-on manifest changes to propagate throughout the community, I advise folks trying to work on this to hold off until one of the following things happen:

1. NVDA 2019.1 is released.
2. Python 3 transition is declared.
3. Python 3 transition is finished.

Thanks.

[derekriemer]

I don't think we should use compat info for addons on the system config. I would disable all addons on the system config, and force the user to check the ones they specifically want.

[ruifontes]

I agree with that, specially because most addons are useless in safe mode...

[zstanecic]

For example, Vocalizer for NVDA 3.0 is useless in safe mode. The configuration is copied, but addon cannoot check the license.

[ruifontes]

Exactly... However I was thinking in all appModules addons... Rui

[JulienCochuyt]

Maybe could we consider adding a key in the add-on manifest defining whether a particular add-on is of any use on the secure screen? Then, we could filter the list of proposed add-on with just those.

@josephsl, what do you think?

[LeonarddeR]

Honestly, I'd rather have no add-ons on secure screens at all. I could only think about the following add-ons that are useful on secure screens:

• Speech synthesizers
• Braille display drivers: note however that they are probably inaccessible on these screens when a logged in user uses the same display
• Vision enhancement providers (vision framework)

I still think that we should incorporate a way into core to make the secure screen copy pipe its output to the logged in copy. That's still problematic when no user is logged in, though.

[lukaszgo1]

Another common use case is having NVDA Remote on secure screens to allow either accepting UAC screens when you are connected to a remote box or simply logging into Windows.

[Brian1Gaff]

Another reason maybe for integrating remote into core then.

[JulienCochuyt]

Honestly, I'd rather have no add-ons on secure screens at all. I could only think about the following add-ons that are useful on secure screens:

• Speech synthesizers
• Braille display drivers: note however that they are probably inaccessible on these screens when a logged in user uses the same display
• Vision enhancement providers (vision framework)

Those three categories are actually the very reason why I think this feature could be useful.

I still think that we should incorporate a way into core to make the secure screen copy pipe its output to the logged in copy. That's still problematic when no user is logged in, though.

IMHO, both approaches are complementary to cover the wider range of use cases.

[derekriemer]

On Sat, Aug 31, 2019 at 3:06 AM Julien Cochuyt ***@***.***> wrote: Maybe could we consider adding a key in the add-on manifest defining whether a particular add-on is of any use on the secure screen? Then, we could filter the list of proposed add-on with just those.

How would the addon know if it is of use to someone on the secure screen?

…

@josephsl <https://github.com/josephsl>, what do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6305?email_source=notifications&email_token=ABI2FPI2HZIJJ4M53WR3CXLQHIYCDA5CNFSM4CNW74T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5TI2IA#issuecomment-526814496>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABI2FPOELZY7OQ6TYIDD6NDQHIYCDANCNFSM4CNW74TQ> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[JulienCochuyt]

How would the addon know if it is of use to someone on the secure screen?

I'd naively say by design and by testing.
It mostly depends on the feature scope of each add-on

Eg.:

• AppModule add-ons do not qualify
• Synth and Braille drivers do if they work there, don't otherwise
• Add-on Updater does not
• ObjPad probably does
• IndentNav probably does not
• WebAccess does not
• FocusHighlight might (needs testing)
• etc

[josephsl]

Hi, regarding ObjPad and other of my add-ons, I plan to harden them by letting them quit while used in secure screens (I mean it). Thanks.

[CyrilleB79]

Hi,
Another one that would be useful in secure screen is Speech history, while Windows updates are installing.

[ExplorerSunil]

Hi
In some corporate settings, it makes sense to let user allow some configuration settings for secure screens or secure mode. E.g. my employer has enabled NVDA only in secured mode, and the startup command look like (so nvda is always on secure screens):

$ nvda.exe -r --secure --log-level=100 --disable-addons

Therefore no configuration settings are saved. Each time NVDA crashes or needs to be restarted, I need to change the voice rate, pitch, synthesizer etc which is very cumbersome.
So I think there should be a way to save these configurations separate from whether addons are allowed or not in these settings. Perhaps that would entail classifying the current settings into two parts one those should be saved for even secured mode and one shouldn't be.
There isn't any option in secure mode for "use currently saved settings on logon and other secured screens" in general tab in NVDA settings. So, that trick doesn't work at all.

@LeonarddeR @nvdaes @josephsl

[josephsl]

Hi,

Thought I came across this earlier...

It might be a bit hard to separate config based on usage in secure screens. One potential workaround is copying settings to NVDA's user config folder manually (that is, while NVDA is not running), but then we run into policy risks.

As for bringing this feature to life, now that all three conditions I mentioned (NVDA 2019.1 or later, Python 3 transition declaration/completion) have been fulfilled, let's work on it. To make the implementation a bit more generic, I propose defining a new dialog class in gui/addonGui module that will be used to check/uncheck add-ons to be copied in the following scenarios:

• Copying regular user config to secure screen configuration (aka system config)
• Creating a portable copy from an installed version and vice versa, and in extension, creating another portable copy from an existing portable copy

Post-condition:

Scenario 1: copying regular config to secure screens:

1. Open general settings panel.
2. Select "copy current configuration to secure screens" button.
3. Present a dialog with the following controls: a warning text about copying settings to secure screens, and if add-ons are detected, a checkable list of add-ons, all unchecked by default.
4. As add-ons are being checked, if needed, enable a checkbox to let users confirm.
5. User clicks "yes" button.
6. Copying proceeds, with the log populated with message about add-ons being copied for debugging purposes.
7. If errors are encountered, present a message, otherwise done.

Scenario 2: creating a portable copy from an installed version and vice versa:

1. Go to NVDA menu/Tools/Create portable copy.
2. Select portable copy folder.
3. Check "copy user configuration" checkbox.
4. Show a checkable list of add-ons as before, but not the confirmation checkbox noted above.
5. Click OK, and only the selected add-ons will be copied.

Scenario 3: installing NVDA from a portable copy: same as above except the checkbox wording will be different.

Points to consider:

1. Exclude disabled add-ons when copying settings: yes for scenario 1, unclear in scenarios 2 and 3 as some add-ons that are disabled in portable copies might be enabled after installation (i.e. Enhanced Touch Gestures add-on which requires an installed copy of NVDA to work correctly).
2. Present a warning about incompatible add-ons: yes if possible for all scenarios.
3. Create separate checkable list controls for each scenario or unify them under one roof: depends on implementation strategy to be used.
4. For scenarios 2 and 3, should the add-ons list be part of create portable copy/install NVDA dialog or a separate dialog: will depend on implementation strategy to be used.

Thanks.

[feerrenrut]

Exclude disabled add-ons when copying settings: yes for scenario 1, unclear in scenarios 2 and 3

I think disabled add-ons should be included in the list. I can imagine situations where an add-on may be specifically required on the logon screen for instance. Forcing that user to enable it on their profile first is pretty inconvenient.

I don't think incompatible add-ons should be listed at all, what's the use case for installing an incompatible addon to system?

The wish list for this could easily explode. Best to start with a simple way of providing the user with better control for copying to system profile. For the first iteration, I would exclude scenarios 2 and 3, and any automatic guessing of appropriate or inappropriate add-ons.

However, I think the first scenario needs more thought, for instance:

Scenario 1b: re-copying settings to system config

1. Complete Scenario 1
2. Change some configuration EG voice rate
3. Re-run scenario 1

In this case, when the dialog opens the add-ons pre-selected should match the add-ons selected by the user the first time.

Scenario 1C: multi user systems (Arguably this is not core to the feature and could be left to a subsequent iteration.)

1. Complete Scenario 1 as User1
2. Log into User2 (who does not have all the same addons eg some the same, some new, missing some)
3. Re-run scenario 1

In this case:

• all add-ons on the system profile should be shown (already ticked)
• add-ons on the system profile not installed to the current user should somehow be marked as such
• all add-ons for the current user only should be shown, only ticked if already on the system profile.

Note:
The first time the system config is set via this dialog, the user should have to decide on the add-ons they want, unselected add-ons should be removed. For this a change to the configspec will be required to list the "user approved add-ons"

In the future we may also need to think about how addon versions fit into this, though I think that should be out of scope for now.

[ruifontes]

Reef Turner escreveu:

I think disabled add-ons should be included in the list. I can imagine situations where an add-on may be specifically required on the logon screen for instance. Forcing that user to enable it on their profile first is pretty inconvenient.

If a disabled add-on will be copied, it will automatically enabled in secure windows? If not, how do you enable it, if there are no access to Add-on manager? Rui Fontes

[feerrenrut]

@ruifontes Good point. There are solutions to this but it will only complicate the initial implementation. For now ignore this goal.

[cary-rowen]

Is there any news about this issue?

[Simon818]

Suggestion: Instead of allowing people to copy addons from general settings at all, have a "enable addon for secure screens" button in the addon manager. This forces users to copy them one by one, and since most people seem to agree that only a small number of addons are useful or necessary on secure screens, it further cuts down on the possibility that someone might just install all their addons to save time.

Somewhat related to that, I think NVDA definitely needs to warn the user when an addon in their systemConfig is older than an update they are currently installing.

[XLTechie]

@Simon818 that is an intriguing idea!

I had already started work on a PR to solve this with a new dialog of checkboxes as was originally desired, but this idea has some merit.

I'm not sure if a button for use (stop using) on secure screens would be best, or possibly a checkbox or combobox, but something in the Add-on Manager does seem interesting.

@feerrenrut is NVA open to this approach?

Regarding your second point @Simon818:

Somewhat related to that, I think NVDA definitely needs to warn the user when an addon in their systemConfig is older than an update they are currently installing.

Agreed, but can you possibly post, if it doesn't exist, a separate issue on this?

[feerrenrut]

@XLTechie, before we can commit to this approach, we have to reach a conclusion about whether add-ons should be allowed on secure screens at all. Please see #13686

Disallowing add-ons on secure screens is a simple fool proof approach to eliminate a whole category of security issues. It has low maintenance cost. Windows intentionally has limited functionality on secure screens, thus should require only minimal functionality from NVDA to support all users.

We are collecting information on required use cases on #13686 so that we can make an assessment.

[Simon818]

@XLTechie That's my plan. I just wanted to wait until the dust settled and we figured out how to move forward with the whole addon thing. I think having an addon copying dialog in general settings is also perfectly fine. Just maybe have everything unchecked by default.

[derekriemer]

What about support addons on secure screens, but only if they are speech or braille drivers?

…

On Thu, May 12, 2022 at 1:39 AM Luke Davis ***@***.***> wrote: @Simon818 <https://github.com/Simon818> that is an intriguing idea! I had already started work on a PR to solve this with a new dialog of checkboxes as was originally desired, but this idea has some merit. I'm not sure if a button for use (stop using) on secure screens would be best, or possibly a checkbox or combobox, but something in the Add-on Manager does seem interesting. @feerrenrut <https://github.com/feerrenrut> is NVA open to this approach? Regarding your second point @Simon818 <https://github.com/Simon818>: Somewhat related to that, I think NVDA definitely needs to warn the user when an addon in their systemConfig is older than an update they are currently installing. Agreed, but can you possibly post, if it doesn't exist, a separate issue on this? — Reply to this email directly, view it on GitHub <#6305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABI2FPKORZ6BNKYNOBZZVFTVJSYRLANCNFSM4CNW74TQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Derek Riemer: Improving the world, one byte at a time. ⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺⠂ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠲ Software engineer, Drive web

[Simon818]

That still leaves us unable to use things like NVDA Remote and Bluetooth Audio, both of which are pretty important to some people. I really feel as though the first step should be adding a way to select them one by one and then evaluate from there, particularly if work is already being done on the code.

[LittleStar-VIP]

Yes, that is a good idea to allow user to copy only specific addon to system config, cause not addons are really useful in the secure screen

[Qchristensen]

It would definitely be good to have a resolution here - I just had a conversation with a user who was struck by the warning and didn't want to allow it because they didn't know how much of a risk continuing would be, and they would be happy to have no add-ons on the logon screen - all they wanted to do to was change their speech rate. The only way currently, to change the secure screens profile and NOT allow add-ons on it (if you already have some installed) - is to completely uninstall all add-ons from your copy of NVDA, set up NVDA how you want on secure screens, save it, use the function to use that on secure screens, then re-install any add-ons you might want.