nvda
nvda copied to clipboard
nvaccess
Added security and privacy note for when installing add-ons to the user guide
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:
- [x] Documentation:
- User Documentation
- [x] Testing:
- Unit tests
- System (end to end) tests
- Manual testing
- [x] 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.
- [x] Security precautions taken.
@lukaszgo1 I have opened this new one and addressed also your review actions. cc: @XLTechie
@lukaszgo1 very probable https://github.com/nvaccess/addon-datastore/pull/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.
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.
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.
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: @.***>
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: @.***>
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 https://github.com/nvaccess/addon-datastore/pull/2660.
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.
@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.
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.
@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: https://github.com/nvaccess/nvda/security/advisories/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/
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
The PR on the data store related to codeQL has been merged, but I think https://github.com/nvaccess/addon-datastore/pull/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.
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?
@Adriani90 I think you misread my comment, we intend to use VirusTotal still, unless a problem with false positives arise
