Added security and privacy note for when installing add-ons to the user guide

[Adriani90]

Link to issue number:

n/a

Summary of the issue:

In many discussions, especially in corporate environments but also when users of other screen readers change to NVDA, there is no common perception of security and privacy status when using add-ons throughout the community of NVDA users.

Description of user facing changes

Users will get a common sense for the perception of the status of security and privacy when using add-ons.

Description of development approach

Discussion #16241 provides more details and current developments.

Testing strategy:

Tested that the formating of the text appears correctly in the user guide, including the link to the community review section.

Known issues with pull request:

None

Code Review Checklist:

• Documentation:
  • User Documentation
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[Adriani90]

@lukaszgo1 I have opened this new one and addressed also your review actions. cc: @XLTechie

[lukaszgo1]

Same here W.R.T. permissions

[lukaszgo1]

As mentioned in the previous PR there is no review process when submitting to the store, so saying there is one create a false sense of security.

[CyrilleB79]

Re the permissions, I agree with @lukaszgo1.

Also the Add-on Store is the one integrated in NVDA, thus being official. There is no need to specify "official".
There are other "unofficial" sources to download add-ons but from what I know, none of them is called Add-on Store.

[Adriani90]

@lukaszgo1 very probable nvaccess/addon-datastore#2660 will be merged into the add-on datastore, so even it is an automatic process, it is still a very basic review which will be implemented. We can wait until that is merged and then merge this one, but definitely there will be a review process on add-on submission or so in the near future.

[Adriani90]

Re permissions, I formulated so that users should read the description of the add-on carefully, some add-on authors who are taking security very seriously will also add notes about permissions of their add-ons (e.g. permission to write their own log file, permission to send a request through internet to generate a description of a picture, etc.) Even though most authors don' describe such things in their add-on descriptions, some of them might do and the users should be aware of this term.
By installing an add-on currently you automatically accept those permissions needed, in Windows there is no permissions system implemented like in IOS but at least the add-on description gives you some orientation on what you will automatically accept when installing it.

[CyrilleB79]

We can wait until that is merged and then merge this one, but definitely there will be a review process on add-on submission or so in the near future.

I would not call it a review but rather a check. The same way, NVDA's checks (linting, unit tests, system tests, etc.) are not called review. Using here the word review is misleading.

[Adriani90]

There were add-ons in the past creating a custom add-on store with an own server infrastructure such as the one created by @yplassiard in the french community. I am pretty sure the japanese community has one as well. So i think calling this one official is ok since there is the possibility of create an alternative one. Von meinem iPhone gesendetAm 17.03.2024 um 14:48 schrieb Cyrille Bougot ***@***.***>: @CyrilleB79 commented on this pull request. In user_docs/en/userGuide.t2t:

@@ -2925,6 +2926,30 @@ If you install an add-on with paid components and change your mind about using i

The Add-on Store is accessed from the Tools submenu of the NVDA menu. To access the Add-on Store from anywhere, assign a custom gesture using the [Input Gestures dialog #InputGestures]. +++ Note on security and privacy when using Add-ons ++[AddonSecurityandPrivacy] +Installing add-ons in NVDA leads to integration of external code into NVDA's functionality in order to enhance NVDA or make new features possible. +Add-ons can also use external libraries and third party services to serve the purpose and provide the features for which they have been developed. +Add-ons can be developed by every person or company, and the review process for these external feature providers happens when they are submitted to the NVDA’s official add-on store. Re the permissions, I agree with @lukaszgo1. Also the Add-on Store is the one integrated in NVDA, thus being official. There is no need to specify "official". There are other "unofficial" sources to download add-ons but from what I know, none of them is called Add-on Store. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[Adriani90]

Could you elaborate on my comment above re permissions? I still think it makes sense to use this term.Von meinem iPhone gesendetAm 17.03.2024 um 14:48 schrieb Cyrille Bougot ***@***.***>: @CyrilleB79 commented on this pull request. In user_docs/en/userGuide.t2t:

@@ -2925,6 +2926,30 @@ If you install an add-on with paid components and change your mind about using i

The Add-on Store is accessed from the Tools submenu of the NVDA menu. To access the Add-on Store from anywhere, assign a custom gesture using the [Input Gestures dialog #InputGestures]. +++ Note on security and privacy when using Add-ons ++[AddonSecurityandPrivacy] +Installing add-ons in NVDA leads to integration of external code into NVDA's functionality in order to enhance NVDA or make new features possible. +Add-ons can also use external libraries and third party services to serve the purpose and provide the features for which they have been developed. +Add-ons can be developed by every person or company, and the review process for these external feature providers happens when they are submitted to the NVDA’s official add-on store. Re the permissions, I agree with @lukaszgo1. Also the Add-on Store is the one integrated in NVDA, thus being official. There is no need to specify "official". There are other "unofficial" sources to download add-ons but from what I know, none of them is called Add-on Store. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[Adriani90]

thanks both of you for the valuable feedback here. @CyrilleB79 I rewrote some part of the note to make clear the difference between checks and review.
This PR is blocked by nvaccess/addon-datastore#2660.

[XLTechie]

"Secure", in a networking context, is a broad and dubious concept. Since I think encryption, and specifically https/TLS verses in-clear transactions is likely what you mean, I have suggested a more exact term.

Suggested change

	- Insecure network connections
	- Using unencrypted network connections

[Adriani90]

@XLTechie thanks alot for your detailed and valuable feedback. INdeed it is not only encryption https / tls, it is also about using insecure ports, intrusion vulnerabilities etc. for example in NVDA remote add-ons or so. Secure or insecure network connections is a more understandable term for users. It is better to keep it.

[XLTechie]

I do not think that "secure port" has the standardized meaning that you seem to think it does. At least, in 30 plus years of networking work, we never used it that way.
Can you provide an RFC explaining what one is please?

Ports are only more or less secure, based upon what momentary traffic is using them, and whether it is encrypted.

Port 443, for example, can just as easily be used for in the clear text communications, as it can for encrypted communications with a web server. It all depends upon what is on the other end of that port (the listener), and what the client expects. It is not the port that is secure, but the protocol used through it.
So saying that add-ons have to use secure ports to be considered more desirable add-ons, is not very meaningful. It's not about the numbers, it's about what the add-on is doing.

I would agree that an add-on should be encrypting any traffic it originates, but even malware does that for purposes of obfuscation, if nothing else.

I agree with @CyrilleB79's question about the target audience of all this.

[XLTechie]

I'm not sure that the second concept logically follows from the first.
I have tried to re-word it several times, and they really just don't go together IMO.

So in addition to a suggestion regarding the first clause, I have expanded the second into its own list item. It says what I think you may have been getting at, although I admit I'm not certain.

Note that also I'm not saying that I personally would include this statement, I'm just suggesting an alternative if you are going to say something like this.

Suggested change

	- The risk of vulnerabilities increases the more add-ons you installed. So be careful to keep the overview of the sources your add-ons come from.
	- The overall risk of vulnerabilities increases the more add-ons you install.
	- Be sure to remain aware of where you are downloading your add-ons from, as sources other than the NVDA Add-on Store may be malicious, may include out of date versions, or may not perform even the limited quality checks that the Store provides.

[Adriani90]

I don't think changing the statement in this way is what I meant. Add-ons in the add-on store can be risky even after automated checks as well because they don't have any human review. So questionable actions performed by an add-on cannot be detected by any statistical security analysis tool. It is still the responsibility of the user currently to deduct from the add-on description and the source of the add-on whether a certain feature is really needed in NVDA or whether it introduces too much vulnerabilities for the subjective feeling of the user.

[CyrilleB79]

I feel this PR is not very clear. We have begun to comment your work in detail (myself included). But in fact, it seems to me that the goal of this PR has not been clearly defined.

• What is the target audience of the additional information provided in this PR? Standard NVDA users, system administrators or both. If both, I think that we should not mix the information that only target system administrators with the information targeting all users.
• For standard users is the goal to explain them basic security concepts? Or is it just to teach them how to check if an add-on can be reliable?

Depending on the provided answer, we can figure which information needs to be provided or not and where:

• in User Guide, in NVDA technical documentation and/or on the Corporate page
• at the beginning or at the end of the Add-on Store paragraph, or even elsewhere in the User Guide.

[XLTechie]

@Adriani90 You posted a link to Microsoft's description of Microsoft Store permissions.
As @CyrilleB79 pointed out already, this is only for the store, and has language that specifically exempts NVDA from being a part of that system.

So even though I acknowledge that Windows does contain a permissions system, and I apologize for speaking too broadly in saying that it doesn't, it does not apply in our context, or to the majority of users.
For this reason, at least until Add-on authors are asked to enumerate resources they use in their descriptions or in some other appropriate field, I will continue to join @lukaszgo1 and @CyrilleB79 in objecting to this assumption of the permissions concept, which does not apply in these circumstances and will lead only to confusion.

I don't believe either of us will be convinced here, so I will not spend further time debating it until something new comes up, or NV Access comments.

I appreciate what you have tried to do with this PR, but at the moment I must conclude that it is very premature. The parts that are applicable now, are already well covered by the Add-on Installation section of the Add-on Store chapter.

One other thing I will point out, is that the more terrifying we make add-ons appear, even though some of them are quite critical for NVDA, the more likely users are to just say "forget it, I won't bother with those dangerous things". We've put all this work into the Store and infrastructure, only to do our best to convince users not to go near them? There seems a messaging disconnect here.

[CyrilleB79]

One other thing I will point out, is that the more terrifying we make add-ons appear, even though some of them are quite critical for NVDA, the more likely users are to just say "forget it, I won't bother with those dangerous things". We've put all this work into the Store and infrastructure, only to do our best to convince users not to go near them? There seems a messaging disconnect here.

I fully agree with this. Before going further with re-writing the User Guide and adding more information in it, we should identify more clearly the current problem:

• do people realize the impact of add-ons regarding security / privacy?
• If not or not totally, why?
• Which information is missing in the User Guide (or elsewhere) and should be provided to the user or sys admin?
• If the information is too technical but still needs to be provided, how should it be explained?

Also @Adriani90, you mention discussions related to the perception of security or privacy by users. If you have any link to provide, it would help us identifying the problem to be addressed. Thanks.

[Adriani90]

@CyrilleB79 wrote:

I feel this PR is not very clear. We have begun to comment your work in detail (myself included). But in fact, it seems to me that the goal of this PR has not been clearly defined.
• What is the target audience of the additional information provided in this PR? Standard NVDA users, system administrators or both. If both, I think that we should not mix the information that only target system administrators with the information targeting all users.

What of that information targets administrators? The description of this PR and the information in the user guide clearly builds awareness for when installing or attempting to install add-ons.
As the PR description states, this is targeting users. Special notes for system admins such as additional command line options etc. are not scope of this PR. also specific information for system admins is rather in scope of the corporate environment section on the NV Access website and the project docs here on github and is also not in scope of this PR.

For standard users is the goal to explain them basic security concepts? Or is it just to teach them how to check if an add-on can be reliable?

It is a mix of both. Building awareness is always a mix of basic concepts and recommendations.

in User Guide, in NVDA technical documentation and/or on the Corporate page

Definitely first of all in the user guide and then with additional information maybe also in the corporate environment page. The corporate environment page targets a specific user group and the system admins probably, while the user guide targets more the standard NVDA users.
In all promotion work related to building awareness (i.e. blogs, etc.) it would be a first step to have a note in the user guide which we can reference to.

at the beginning or at the end of the Add-on Store paragraph, or even elsewhere in the User Guide.

I think since it directly impacts add-ons and user's perception, it is good to have them at the beginning, but if you have another proposal feel free to suggest and I can move it.

@XLTechie wrote:

The parts that are applicable now, are already well covered by the Add-on Installation section of the Add-on Store chapter.

I don't think so, it is verylimited and still not enough to build enough awareness.

One other thing I will point out, is that the more terrifying we make add-ons appear, even though some of them are quite critical for NVDA, the more likely users are to just say "forget it, I won't bother with those dangerous things". We've put all this work into the Store and infrastructure, only to do our best to convince users not to go near them? There seems a messaging disconnect here.

It is not about making add-ons terifying, it is about informing the users. Even though we have an add-on store in place, this does not mean we should be intransparent to these topics that are in fact very important when using add-ons in any kind of situation, whether it is NVDA or not.
I don't see the risk that users will step back from add-ons, i rather see a chance that add-on authors will describe their add-ons better when dealing with more educated users who review the add-ons in a more advanced way.
Currently we have a very inflationary environment with over 250 add-ons out there, from different add-on stores and external sources, no reviews at all and lots of people enabling incompatible add-ons. If you enable incompatible add-ons after you informed yourself, fair enough. But hiding the potential risks that might occur for users from them when installing add-ons is in my view a very bad practice. The user guide is the very first step we can take to inform and then it can be expanded if required to other more sofisticated aspects.

@CyrilleB79 wrote:

do people realize the impact of add-ons regarding security / privacy?

Some yes, but the majority I would say not really because there is no promotion on this topic like it was in the past when the community reviewed every add-on. So building sustainable awareness is crucial.

Which information is missing in the User Guide (or elsewhere) and should be provided to the user or sys admin?

I will not comment on sys admin because it is out of scope for this PR, but I added information that is not in the user guide yet and so for a standard NVDA user not really elsewhere when it comes to recommendations from this point of view.

If the information is too technical but still needs to be provided, how should it be explained?

This is out of scope for this PR. This PR targets awareness and not technically sofisticated documentation. That's why I don't want to define permissions from a technical point of view, permissions is a general term that exists whether there is a technical notification / confirmation promt or not.

you mention discussions related to the perception of security or privacy by users. If you have any link to provide, it would help us identifying the problem to be addressed. Thanks.

No problem, here some discussions on the international mailing lists, but I also have very long discussions on this topic in the local communities in german and romanian language. It is really not ideal that we have to give such advices to users everytime via mailing lists and via personal conversations and there is no note in the user guide with some recommendations.
https://nvda.groups.io/g/nvda/topic/101342786#111251
https://nvda.groups.io/g/nvda/topic/security_issue_and_addon_on/89545511?p=,,,20,0,0,0::recentpostdate/sticky,0,,20,0,2000,89545511,previd%3D1646264432528296695,nextid%3D1646753061946857775&previd=1646264432528296695&nextid=1646753061946857775
https://nvda.groups.io/g/nvda/topic/97247411?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2C%2C20%2C0%2C20%2C97247411
https://nvda.groups.io/g/nvda/message/40993

And here a github security issue by Sean, this makes life easier for system admins ofcourse, but there is still the user''s perspective that needs to be aware of certain things aas well:
GHSA-727q-h8j2-6p45
But for standard users we cannot get in such details in the user guide, so the promotion work will have to be done via blogs and conversations. Though some standard aspects should be covered in the user guide which I try to do via this PR.

There were some security and privacy notes on the community add-ons review process, though they are now kind of deprecated due to low activity so there is no awareness comming from that side:
https://addons.nvda-project.org/processes.en.html

And moreover, there are currently possibilities that add-on stores are merged to provide access to more add-ons in a convenient way for certain user groups. Already the fact that someone can build up the official add-on store as a website and put things in it that NV Access didn't put into the official add-on store might introduce risks so users should be aware of some general recommendations.
See for example this mirror of the add-on store:
https://nvda.store/

[Adriani90]

Maybe one concrete example for a malitious add-on we could luckily detect is this one. Actually we should have added such a note into the user guide already at that time:
https://addons.nvda-project.org/addons/blindExtra.en.html
https://nvda-addons.groups.io/g/nvda-addons/topic/blind_extra_is_back/31684377

[Adriani90]

The PR on the data store related to codeQL has been merged, but I think nvaccess/addon-datastore#3294 will also be a nice add and I would update the note accordingly also after #16434 is fixed.
So I think the blocked label is still appropriate here.

[Adriani90]

It seems it has been decided to not implement virus total checks because this would result in too many false positives being detected.
@seanbudd, @Qchristensen is the blocked label now obsolete? Or are there any further decisions you need to take internally?

[seanbudd]

@Adriani90 I think you misread my comment, we intend to use VirusTotal still, unless a problem with false positives arise

[Adriani90]

@Qchristensen this is now re-drafted in md and ready for another review.

[CyrilleB79]

Just a detail:
There is no concept of "official" Add-on Store and unofficial ones. The Add-on Store is just a part of NVDA as the settings dialog or the update window is. There is just the Add-on Store, and alternative ways to download add-ons. Thus I'd drop "official".

Suggested change

	* The risk of vulnerabilities increases the more add-ons you installed. Therefore, be sure to remain aware of where you are downloading your add-ons from. Sources other than the official NVDA Add-on Store may be malicious, may include out of date versions, or may not perform any quality checks.
	* The risk of vulnerabilities increases the more add-ons you installed. Therefore, be sure to remain aware of where you are downloading your add-ons from. Sources other than NVDA's Add-on Store may be malicious, may include out of date versions, or may not perform any quality checks.