temporary Screen curtain deactivates after say all profile or manual profile trigger

[ondrosik]

Steps to reproduce:

1. create say all profile and change something (in my situation something in eSpeak). Do not touch screen curtain
2. get back to the normal profile
3. Enable temporary screen curtain
4. invoke say all
   NVDA will disable screen curtain

Log looks like this:

Input: kb(laptop):NVDA+a
DEBUG - config.ConfigManager._triggerProfileEnter (11:08:21.291) - MainThread (15296):
Activating triggered profile citanie (name of the profile)
DEBUG - synthDriverHandler.SynthDriver.loadSettings (11:08:21.291) - MainThread (15296):
Loaded changed settings for SynthDriver espeak
DEBUG - autoSettingsUtils.autoSettings.AutoSettings._saveSpecificSettings (11:08:21.291) - MainThread (15296):
Saved settings for ScreenCurtainSettings
DEBUG - visionEnhancementProviders.screenCurtain.ScreenCurtainProvider.terminate (11:08:21.291) - MainThread (15296):
Terminating ScreenCurtain

Additional info:

• the same situation can be reproduced when you enable temporary screen curtain and manually activate profile where there is no setting related to screen curtain.
• This doesn't affect normal Screen curtain, this works as expected.

If this behavior is intentional, I think that we need to modifi somehow the explanation of temporary screen curtain e. g. that restart and profiles will disable it.

[LeonarddeR]

Hmm, this is a tricky one. The temporary curtain is active until the next configuration change. If the config profile is switched, the vision handler disables providers that are not active in the configuration.

[fisher729]

Hi.

I think the implementation of screen curtain is very tricky and confusing at best. Why there was a temporary feature, I do not know, when there are profiles at play in NVDA, as well as reverting saved settings and the ability to manually save settings. It is not intuitive in my opinion. There should only be two modes...on or off.

[LeonarddeR]

The temporary mode was implemented for people who would like to have Screen Curtain enabled on a temporary basis, until they restart NVDA. This applies to people who don't use screen curtain as a default.

[fisher729]

Yes, but the use cases don't warrant the need for a temporary screen curtain. If someone wants the screen curtain setting to temporarily be available, then they could either create a profile with it enabled or uncheck saving of configuration profiles when NVDA is exited. They could also disable the screen curtain after use. This mirrors what is seen in other screen reader products. The temporary screen curtain is also not intuitive because it warrants the pressing of the key twice to permanently enable the curtain, but one press to disable it entirely. This permanency is also dependent on if saving of settings when NVDA exits is checked. I think the add-on did a better job. Screen curtain should just be toggled on and off.

…

On 4/27/20, Leonard de Ruijter ***@***.***> wrote: The temporary mode was implemented for people who would like to have Screen Curtain enabled on a temporary basis, until they restart NVDA. This applies to people who don't use screen curtain as a default. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #11062 (comment)

[feerrenrut]

@LeonarddeR I can see the appeal to making screen curtain settings global (not tied to a profile). What is the use case for profiles with screen curtain? Or another option is to make gestures override the current profile.

[LeonarddeR]

The config profile support is actually one of my main use cases for the screen curtain. Applications I don't want people to see what I'm doing in are tied to a profile that enables the curtain when I'm in that app.

[CyrilleB79]

@LeonarddeR IMO screen curtain should be a global setting because we cannot guarantee that privacy is honored if this setting is profile-dependant. Worse, it makes believe the user that he has a guaranteed privacy whereas it is not always the case.
Here is a usecase demonstrating it:
I make a profile for Firefox to have screen curtain enabled in this app only so that I can check sensitive information online, e.g. online bank. Firefox window is maximized thus it takes the whole screen.
While I am browsing the bank's website, another app's window pops up. This could be a modal window or just a window that comes on foreground, e.g. add-on updater reminds me that some add-ons need to be updated.
In this case, the profile switches to normal one since add-on updater window does not belong to Firefox. This profile change triggers screen curtain de-activation. Since add-on updater window does not cover the whole screen, a part of Firefox window content with sensitive information can be seen.

[XLTechie]

I would agree completely with @CyrilleB79. I do not think people expect this setting to be profile-dependent, either, as most (all?) other systems that support a screen curtain, either have it globally on or globally off. There is no circumstantial application of the screen curtain.

[feerrenrut]

make screen curtain gestures override the current profile.

I think both concerns could be resolved with this. Couple that with the request for audible feedback during every enable / disable of screen curtain (issue #10692) and the user should be well informed about the current state.

With this approach there is a corner case to consider:
"When using a gesture to disable screen curtain, when the current profile typically would enable screen curtain". In this case I think screen curtain should be disabled, and re-enabled at the next profile trigger. However, in the opposite case:
"When a gesture was used to enable screen curtain, and a profile is activated which would disable screen curtain". Screen curtain should stay enabled.

This allows those who prefer an automatic approach to rely on it, and override it when necessary. Those who prefer a manual approach don't have to worry about this being applied to their current profile settings.

[CyrilleB79]

make screen curtain gestures override the current profile.

I think both concerns could be resolved with this.

@feerrenrut do you include the pop-up window use case in the "both concerns" you mention? If yes, could you elaborate on this taking the same use case as example? I do not understand why making screen curtain gestures override the current profile resolves the issue.

[fisher729]

Hi. I can actually see the need for application/profile specific screen curtain, similar to what the add-on provided. For those persons that want it to be turned on and off only, they can use the normal configuration profile to do so, or deactivate any running profiles and toggle it. This would be consistent with all of NVDA's other settings, barring the general ones. However, the temporary and permanent screen curtain confuses things, as it is not consistent with NVDA's settings where profiles are taken into account.

…

On 4/29/20, CyrilleB79 ***@***.***> wrote: > > make screen curtain gestures override the current profile. > > I think both concerns could be resolved with this. @feerrenrut do you include the pop-up window use case in the "both concerns" you mention? If yes, could you elaborate on this taking the same use case as example? I do not understand why making screen curtain gestures override the current profile resolves the issue. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #11062 (comment)

[feerrenrut]

@feerrenrut do you include the pop-up window use case in the "both concerns" you mention? If yes, could you elaborate on this taking the same use case as example? I do not understand why making screen curtain gestures override the current profile resolves the issue.

My understanding of this concern:

• As a blind user I want to be able to manually enable screen curtain knowing it will not be disabled under any circumstances. This is so that I can be confident that despite changing applications and potential unanticipated popup windows my screen will not become visible.

To achieve this, manual screen curtain activation (via the gesture) overrides any profile setting.
Step by step:

• The user decides they want screen curtain enabled for the duration of their session / always.
• They use an input gesture to enable screen curtain (either temporarily or permanently)
• The continue with their task
• A pop-up window takes focus activating a profile in which screen curtain is disabled.
• The setting enabled by the screen curtain gesture overrides the current profile.
• Result: screen curtain is not disabled.

[CyrilleB79]

@feerrenrut thanks for clarification. So the use case of manual activation seems clear to me and a profile switch would not interfere with it.

Anyway, unless I have missed something, the activation triggered by profile switch does not address privacy concerns, as described in the pop-up window use case. Another use case that does not guarantee privacy is the following:

• Again let's imagine Firefox's profile is configure to enable screen curtain and normal profile to disable it.
• I am working in Firefox on sensitive information. As usual Firefox window is maximized.
• Then I open Windows calculator, what triggers screen curtain de-activation.
• Windows calculator's window is not maximized (what a blind user cannot check easily). Thus a part of Firefox's window can be seen around calculator's window.
  This means that the user should be careful not to close Firefox before using another application/window. And he should be conscious of that when configuring the screen curtain in a profile.

For me, the pop-up window use case and this not maximized window use case are two use case that may break the user's privacy when he expects it to be guaranteed.

@LeonarddeR could you please comment on these 2 use case and their impact on privacy? Maybe also I have missed another use case where profile-dependant screen curtain activation would be more interesting.
Thanks.

[LeonarddeR]

I don't fully understand this idea of @feerrenrut I'm afraid. As far as I know, a profile switch should not disable a permanently enabled screen curtain unless it was once explicitly disabled within that profile. If it was once disabled within a profile, disabling the screen curtain could have been done for a particular reason.

The problem is temporary activation. If the curtain is temporary activated, the config doesn't change. After a profile switch, the current state of the provider is compared against the complete NVDA config with the profile active, not just the profile. I think this is were the culprit really is. The state of the curtain should only be changed if there is an explicit configuration key in just the profile itself.

[feerrenrut]

I'm trying to avoid getting bogged down with the limitations of the implementation, and think in terms of user outcomes here.

My assertions:

• "if a user manually enables screen curtain with a gesture, they don't want it disabled by anything other than a gesture, or exiting NVDA only in the case of temporary activation"
• "A user who regularly enables and disables screen curtain for particular apps / workflows, does not want to have to do so manually. They can configure profiles that enable / disable screen curtain depending on what application currently has focus"

There are of course some limitations to the way that profiles activate and deactivate that may not make it acceptable for every persons workflow, EG popups. However it could be useful for certain very well defined work flows. Particularly short lived ones.

I'm suggesting that both gestures (permanent and temporary) screen curtain enable get their own settings that live only in the base config. This is in addition to the settings panel config option that can be used by profiles. When this setting is enabled it overrides any other profile (GUI) setting for screen curtain.

[LeonarddeR]

This makes sense.

[CyrilleB79]

However it could be useful for certain very well defined work flows. Particularly short lived ones.

Could you give a real life example please? Sorry but I really cannot figure such use cases since I am only a rare user of screen curtain, and I did never need to have it profile dependent.

I also fear that the screen curtain option be difficult to understand clearly for all users: temporary vs. definitive, global shortcut vs. profile-associated setting, etc. Hence my comments.

[feerrenrut]

Could you give a real life example please?

A user with a password manager, such as keepass. They open keypass, find the correct account, get the app to copy the password and paste it into their application. All secrets/passwords in keepass are hidden already, but the user doesn't want someone looking over their shoulder to know what other accounts they have. To cater to this they might set up a profile specifically to enable screen curtain for keepass.

I also fear that the screen curtain option be difficult to understand clearly for all users

I understand, these different parts add complexity, but they don't have to make the feature complicated. Most users don't need to understand all parts of the feature. Understanding and using profiles correctly is for more advanced users already, and I believe there are several improvements we could make to profile configuration to make it easier to understand also. Right now, we have a plan to address the core issue raised. Once that is implemented we can check again if the feature seems complicated for users.

[CyrilleB79]

OK thanks for the example. Again, privacy is not guaranteed, but as you explained, for applications that are used in a limited gap of time, the risk to see privacy compromised is reduced. The user should just be aware of it when using profiles.
I suggest that we add a note about this in the documentation once the feature is clearly defined and developped.

[Adriani90]

very related, if not duplicate of #10476.

[CyrilleB79]

Just adding here another very frequent example of privacy compromission:
If you use a profile with screen curtain for your password manager, when you alt+tab from your password manager to your browser (and until you have not released the alt key), the task switching window takes the focus and the password manager application is visible in the background of the task switching window, all around the task switching window.
To be clear, the screen curtain is switched off as soon as the task switching window appears when the password manager's window is still visible in the background.

[Adriani90]

@LeonarddeR you said in #11062 (comment)
that this is tricky to fix. But is it not possible to apply the same principle as for sleep mode when pressing nvda+ctrl+escape once? As far as I understand sleep mode does not save to profile ini files, and still can be enabled on an app basis.

[CyrilleB79]

@gerald-hartig or @seanbudd could you triage and set a priority to this issue? Having a privacy-related issue untriaged for such a long time makes it less easily trackable and thus it is quite uncomfortable.

[CyrilleB79]

By the way, maybe the development of NVDA magnifier could be the opportunity to review and simplify screen curtain code and use cases.

[LeonarddeR]

I guess the sleep mode approach could be considered, but I don't see how that would solve the problem with app specific triggers, and that's also a valid concern. Thinking more and more about this, may be we should just crack the nut and make vision a global section anyway.

[CyrilleB79]

Thinking more and more about this, may be we should just crack the nut and make vision a global section anyway.

I guess that there are real use cases for vision providers to remain profile specific. That's useful to enable/disable focus highlighters manually, and it will probably be also very useful with various configurations of the future NVDA magnifier.

Much more interesting would be to remove screen curtain from vision providers / vision panel and make it a global (no profile) parameter, as are general settings. As I already wrote in other discussions, having screen curtain in the vision panel is an aberration: screen curtain is not a visual aid but a privacy feature.