search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.11k stars 636 forks source link

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

Open LeonarddeR opened 8 years ago

LeonarddeR commented 8 years ago

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 commented 8 years ago

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

LeonarddeR commented 7 years ago

@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 commented 7 years ago

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 < notifications@github.com> 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 https://github.com/nvaccess/nvda/issues/6305#issuecomment-276121150, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGiveOscO4Cdn3pz59EIXR6OH7Q_3c6ks5rXhftgaJpZM4Jtv8n .

--

Derek Riemer: Improving the world one byte at a time!

Personal website http://derekriemer.com

josephsl commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

josephsl commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

zstanecic commented 5 years ago

For example, Vocalizer for NVDA 3.0 is useless in safe mode.

The configuration is copied, but addon cannoot check the license.

ruifontes commented 5 years ago

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

Rui

JulienCochuyt commented 5 years ago

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 commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

Another reason maybe for integrating remote into core then.

JulienCochuyt commented 5 years ago

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 commented 5 years ago

On Sat, Aug 31, 2019 at 3:06 AM Julien Cochuyt notifications@github.com 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 https://github.com/nvaccess/nvda/issues/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!

Personal website http://derekriemer.com

JulienCochuyt commented 5 years ago

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.:

josephsl commented 5 years ago

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 commented 4 years ago

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

ExplorerSunil commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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

cary-rowen commented 3 years ago

Is there any news about this issue?

Simon818 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 https://github.com/nvaccess/nvda/issues/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 commented 2 years ago

@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 commented 2 years ago

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 https://github.com/nvaccess/nvda/issues/6305#issuecomment-1124638459, 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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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.