Is your feature request related to a problem? Please describe.
Add-ons are currently installed to AppData, a user specific folder generally used for holding app configuration and data.
Add-ons are executable code, that runs at a system level.
Windows is designed to protect the system from installation of dangerous code through using the Write protected folders for Program Files.
Code that must run at a system level is generally installed to program files, and protected by UAC administrator approval for installation.
A commonly raised security concern is that NVDA users can install malicious add-ons, meaning that a malicious or naïve user can wreak havoc on their system.
Secure mode prevents the installation or modification of add-ons, however in many environments secure mode is overkill.
By installing add-ons to Program Files, and requiring admin approval for each install, we are following the common Windows patterns associated with installing potentially dangerous software.
By performing the UAC approval on a per add-on basis, users may better understand the risk involved, and approach with the same caution that they would when installing any software with a UAC prompt.
Describe the solution you'd like
Installing add-ons to program files would ensure that administrator approval is required for the installation of any add-on.
It would have the side affect of installing add-ons for all users of a machine, so different users of the same machine would have to disable/enable desired installed add-ons on their own profile.
Add-on authors would probably have to be conscious of the change, differentiating between the add-on installation folder, and the add-on individual user config folder.
As such, this is probably an API breaking change.
For portable copies, this won't be a significant change, as the config directory is stored within the portable copy and portable copies are can be inherently packaged with arbitrary insecure code.
Describe alternatives you've considered
The current warning system conveys appropriate risk, and administrators are able to prevent modification/installation of add-ons with secure mode.
As such, this change is not of a large material benefit.
This proposal just aims to align the process with a common UX for windows.
Additional context
Other extension libraries generally don't require a UAC prompt to install an add-on, but these extension systems generally aren't as risky as NVDA, and are safely sandboxed.
Is your feature request related to a problem? Please describe.
Add-ons are currently installed to AppData, a user specific folder generally used for holding app configuration and data.
Add-ons are executable code, that runs at a system level.
Windows is designed to protect the system from installation of dangerous code through using the Write protected folders for Program Files.
Code that must run at a system level is generally installed to program files, and protected by UAC administrator approval for installation.
A commonly raised security concern is that NVDA users can install malicious add-ons, meaning that a malicious or naïve user can wreak havoc on their system.
Secure mode prevents the installation or modification of add-ons, however in many environments secure mode is overkill.
By installing add-ons to Program Files, and requiring admin approval for each install, we are following the common Windows patterns associated with installing potentially dangerous software.
By performing the UAC approval on a per add-on basis, users may better understand the risk involved, and approach with the same caution that they would when installing any software with a UAC prompt.
Describe the solution you'd like
Installing add-ons to program files would ensure that administrator approval is required for the installation of any add-on.
It would have the side affect of installing add-ons for all users of a machine, so different users of the same machine would have to disable/enable desired installed add-ons on their own profile.
Add-on authors would probably have to be conscious of the change, differentiating between the add-on installation folder, and the add-on individual user config folder.
As such, this is probably an API breaking change.
For portable copies, this won't be a significant change, as the config directory is stored within the portable copy and portable copies are can be inherently packaged with arbitrary insecure code.
Describe alternatives you've considered
The current warning system conveys appropriate risk, and administrators are able to prevent modification/installation of add-ons with secure mode.
As such, this change is not of a large material benefit.
This proposal just aims to align the process with a common UX for windows.
Additional context
Other extension libraries generally don't require a UAC prompt to install an add-on, but these extension systems generally aren't as risky as NVDA, and are safely sandboxed.