managing add-ons for secure screens

[mdlawler]

The new ability for allowing the user to select which add-ons for secure screens is a nice start, but I see several issues/limitations with it.

1. All users coming from older versions of NVDA will still have all add-ons because the feature doesn't have a way for the user (or if not just doing it automatically) to remove existing secure screen add-ons.
2. Maybe this should be put into the add-on store instead and then it could show the current secure screen add-ons, whether or not they are out of date, or if they are only available for secure screens, but have been removed from the non-secure screens add-ons. This would allow the user and system admins to quickly see what add-ons were available on secure screens and whether or not they are out of date.
   I really like the idea of moving this management to a tab in the add-on store dialog as it seems to offer the most flexibility for users and admins alike.

[makhlwf]

What if add-ons had a tag in their manifest that tells NVDA that this add-on is safe to use in secure screens? If an add-on doesn't include this tag, it will not be available to be selected for the secure screens version of NVDA, and reviewers will decide if an add-on that has this tag is really useful to include in the secure screens. Otherwise, ask the add-on author to clarify or remove the tag. I think this is a good addition to this suggestion.

[CyrilleB79]

Yes, the new possibility to choose to copy only some add-ons is already an improvement, but I agree that not being able to see which add-ons are installed in the system profile is a missing feature. While there is an automatic update mechanism via the add-on store, the system profile can still remain with outdated add-ons, which is a problem when add-on updates fix security issues.

To summarize, in the less risky environment of the user session, NVDA provides a nice UX that makes it easy to keep add-ons up to date. But in the more sensitive environment of secure screens (system profile), it provides a much less efficient way to keep add-ons up to date, relying more on users.

Moreover, it displays two successive, very similar warnings in these dialogs, leading to warning fatigue, which may cause the opposite effect from the one intended. I had already raised this concern in the original PR, but my comment on this topic did not result in any wording / design change.

In addition to these warnings, I feel that the wording of the related options in the General settings and the subsequent wording in the copy add-ons dialog are not well aligned. For example the title of the window mentions the system-wide configuration, but the General settings panel do not. Maybe we should just rename the button in General settings "Manage system-wide configuration used for logon.

I have not had so much time to think about it and suggest a better design but I really think that the UX of this new feature is sub-optimal.

Cc @SaschaCowley

[SaschaCowley]

Thanks all for your feedback.

@mdlawler

1. All users coming from older versions of NVDA will still have all add-ons because the feature doesn't have a way for the user (or if not just doing it automatically) to remove existing secure screen add-ons.

We are aware of this limitation, and thought about it when implementing the feature. However, the update process currently doesn't touch the system-wide configuration, so modifying which add-ons are present there when updating would require a lot of careful thought, design and testing. Simply removing all add-ons when performing the update risks making NVDA inoperable on secure screens for users who rely on certain add-ons to use their machine (e.g. the only TTS that supports their language is an add-on, or they are a braille-only user whose braille display requires an add-on).

2. Maybe this should be put into the add-on store instead and then it could show the current secure screen add-ons, whether or not they are out of date, or if they are only available for secure screens, but have been removed from the non-secure screens add-ons.

This is an interesting suggestion. We are a little concerned that it creates a confusing user experience, especially for less technical users. We can certainly see the appeal and that it does solve some problems.

---

@CyrilleB79

but I agree that not being able to see which add-ons are installed in the system profile is a missing feature.

I've created #19550 which partially addresses this concern. It also speaks to the concern about updating add-ons, though still relies on manual action.

While there is an automatic update mechanism via the add-on store, the system profile can still remain with outdated add-ons, which is a problem when add-on updates fix security issues.

To summarize, in the less risky environment of the user session, NVDA provides a nice UX that makes it easy to keep add-ons up to date. But in the more sensitive environment of secure screens (system profile), it provides a much less efficient way to keep add-ons up to date, relying more on users.

We could probably inform users when updating add-ons if the add-on also needs to be updated in the system config, and possibly even offer an option to automatically do so, though this would need to be done after NVDA has restarted to complete the update process. There's still an open question about add-ons that are installed to the system config but not individual users' configs, as they will never get update notifications. I expect this case is rare and we may decide that not having automatic update checks in this case is fine.

Moreover, it displays two successive, very similar warnings in these dialogs, leading to warning fatigue, which may cause the opposite effect from the one intended.

NV Access's stance on this is that both warnings are necessary and perform separate functions.

In addition to these warnings, I feel that the wording of the related options in the General settings and the subsequent wording in the copy add-ons dialog are not well aligned. For example the title of the window mentions the system-wide configuration, but the General settings panel do not. Maybe we should just rename the button in General settings "Manage system-wide configuration used for logon.

I kept the current button text as I thought it was more self-explanatory, particularly for non-technical users. I'm also hesitant about the word "manage" as this seems to me to imply a level of flexibiility that is simply not present currently.

I have not had so much time to think about it and suggest a better design but I really think that the UX of this new feature is sub-optimal.

Perhaps working on #18303 may yield a more satisfactory user experience.

---

@makhlwf

What if add-ons had a tag in their manifest that tells NVDA that this add-on is safe to use in secure screens?

I'm not sure what this achieves. Since add-ons are not vetted by anyone, a malicious add-on could include this tag. It would also block add-ons that may be legitimately necessary from being used on secure screens.

reviewers will decide if an add-on that has this tag is really useful to include in the secure screens. Otherwise, ask the add-on author to clarify or remove the tag.

Add-ons do not require any form of review in order to be used with NVDA. Indeed, even the Add-on store makes no guarantees about the quality, stability, security or functionality of add-ons, which receive essentially no official human review.

[mdlawler]

I'm still learning how to use git so don't know how to create links and such. If there is a tutorial on this I'd be happy to read it. I actually like 19550 a lot. The only big issue left is there needs to be a way to remove add-ons that are already installed in the systemconfig folder. Having this along with 19550 would at least make management possible. With 19550 and the current implementation to select which add-ons to copy we could do everything but remove installed add-ons. Perhaps we could check add-ons in the list that were already installed and press a remove button from the dialog as well. It might not be perfect, but it would at least allow for full management in 2026.1 since you already plan on implementing 19550 for that mile stone.

[SaschaCowley]

When copying user config to the system config, the user config completely replaces the system config. Thus, to remove add-ons from the system config, you would select to copy all add-ons that you do want to be part of the system config when copying configuration.

[mdlawler]

I copied 6 add-ons and get

Volume in drive C is unlabeled Serial number is aca3:859b
Directory of C:\Program Files\NVDA\systemConfig\addons*

2/03/2026 3:49

.
2/03/2026 3:49 ..
2/03/2026 3:49 capitalSelectionIndicator
2/03/2026 3:49 EnhancedFindDialog
2/03/2026 3:49 gestureDuplicate
2/03/2026 3:49 goldenCursor
2/03/2026 3:49 toolbarsExplorer
2/03/2026 3:49 ttusb
1/23/2026 2:28 1,498 capitalSelectionIndicator.json
1/19/2026 2:49 1,480 EnhancedFindDialog.json
1/19/2026 2:59 1,251 gestureDuplicate.json
8/26/2025 2:19 907 goldenCursor.json
1/19/2026 3:24 1,196 toolbarsExplorer.json
6,332 bytes in 5 files and 8 dirs 20,480 bytes allocated
837,468,639,232 bytes free

Then I copied 1 add-on and get

Volume in drive C is unlabeled Serial number is aca3:859b
Directory of C:\Program Files\NVDA\systemConfig\addons*

2/03/2026 3:50

.
2/03/2026 3:50 ..
2/03/2026 3:50 ttusb
1/23/2026 2:28 1,498 capitalSelectionIndicator.json
1/19/2026 2:49 1,480 EnhancedFindDialog.json
1/19/2026 2:59 1,251 gestureDuplicate.json
8/26/2025 2:19 907 goldenCursor.json
1/19/2026 3:24 1,196 toolbarsExplorer.json
6,332 bytes in 5 files and 3 dirs 20,480 bytes allocated
837,470,257,152 bytes free
It is copying the .json files which it shouldn't

The systemconfig dir shows

Volume in drive C is unlabeled Serial number is aca3:859b
Directory of C:\Program Files\NVDA\systemConfig*

2/03/2026 3:49

.
2/03/2026 3:49 ..
2/03/2026 3:49 addons
2/03/2026 3:49 addonStore
2/03/2026 3:49 profiles
2/03/2026 3:49 speechDicts
2/03/2026 3:49 updates
2/03/2026 3:49 232 addonsState.pickle
1/21/2026 18:10 203 gestures.ini
2/02/2026 20:25 180 IBMTTSUpdateState.pickle
2/02/2026 20:27 431 mathcat.yaml
2/02/2026 20:32 7,957 nvda.ini
11/19/2024 15:52 42 profileTriggers.ini
12/10/2024 19:25 338 symbols-en.dic
2/02/2026 6:40 273 updateCheckState.pickle
9,656 bytes in 8 files and 7 dirs 36,864 bytes allocated
837,468,639,232 bytes free
It seems to me that these should also be skipped.

2/03/2026 3:49

addonStore
2/03/2026 3:49 updates
2/03/2026 3:49 232 addonsState.pickle
2/02/2026 20:25 180 IBMTTSUpdateState.pickle
2/02/2026 20:27 431 mathcat.yaml
2/02/2026 6:40 273 updateCheckState.pickle

[mdlawler]

I think if you implemented 19550 and when updating an add-on either automatically or manually checked to see if it was in systemconfig and offered to updated this would cover things fairly well and would also have the benefit of having simple UI.