Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Adriani90
Copy link
Collaborator

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 Adriani90 requested a review from a team as a code owner March 17, 2024 09:21
@Adriani90 Adriani90 requested a review from Qchristensen March 17, 2024 09:21
@Adriani90
Copy link
Collaborator Author

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

user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
The review process of add-ons is still in development, so most of add-ons are not reviewed yet.
However, many add-ons have discussions areas where users can exchange feedback. The [community review area #AddonStoreReviews] can be accessed via the actions menu of the add-on.

Installed Add-ons or extensions (not only in NVDA) might in general introduce security and/or privacy vulnerabilities, depending on the permissions they need and actions they perform in order to provide the desired functionality.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here W.R.T. permissions

++ 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link
Collaborator Author

Adriani90 commented Mar 17, 2024 via email

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Mar 17, 2024 via email

@Adriani90
Copy link
Collaborator Author

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.

user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved

Installed Add-ons or extensions (not only in NVDA) might in general introduce security and/or privacy vulnerabilities, depending on the permissions they need and actions they perform in order to provide the desired functionality.
Risks can be e.g.
- Insecure network connections
Copy link
Collaborator

@XLTechie XLTechie Mar 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
user_docs/en/userGuide.t2t Outdated Show resolved Hide resolved
- Check out the developer’s website to see if it’s a serious source you can trust.
- Read the description carefully. Does the add-on need questionable permissions? Does it track data? Does it share sensitive data with other sources that you don’t trust?
- Check out the [community reviews #AddonStoreReviews] for the add-on. Are there any complaints about the add-on? Are there any reports about data being taken, or for anything that makes you feel unsafe?
- 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.
Copy link
Collaborator

@XLTechie XLTechie Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

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
Copy link
Collaborator

XLTechie commented Mar 19, 2024

@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
Copy link
Collaborator

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 Adriani90 changed the title Added security and privacy note for add-ons to the user guide Added security and privacy note for when installing add-ons to the user guide Mar 19, 2024
@Adriani90
Copy link
Collaborator Author

Adriani90 commented Mar 19, 2024

@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
Copy link
Collaborator Author

Adriani90 commented Mar 19, 2024

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

@seanbudd seanbudd added blocked/needs-product-decision A product decision needs to be made. Decisions about NVDA UX or supported use-cases. blocked/needs-internal-fix labels Apr 16, 2024
@Adriani90
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Member

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

@Adriani90 Adriani90 force-pushed the SecurityandPrivacyNotes branch from 3133208 to 7d61214 Compare May 9, 2024 10:04
@Adriani90
Copy link
Collaborator Author

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

…tyandPrivacyNotes

# Conflicts:
#	user_docs/en/userGuide.md
@Adriani90 Adriani90 force-pushed the SecurityandPrivacyNotes branch from ee00c8c to 589303e Compare November 15, 2024 13:55
@Adriani90
Copy link
Collaborator Author

@SaschaCowley conflicts are fixed, is this still blocked by something?

@seanbudd
Copy link
Member

seanbudd commented Dec 2, 2024

@Adriani90 - we are yet to scan every add-on retroactively submitted to the add-on store. We want to confirm all add-ons have been scanned before mentioning virustotal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked/needs-internal-fix blocked/needs-product-decision A product decision needs to be made. Decisions about NVDA UX or supported use-cases. blocked merge-early Merge Early in a developer cycle
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants