Added security and privacy note for when installing add-ons to the user guide #16316
Conversation
|
@lukaszgo1 I have opened this new one and addressed also your review actions. cc: @XLTechie |
user_docs/en/userGuide.t2t
Outdated
| 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. |
There was a problem hiding this comment.
Same here W.R.T. permissions
user_docs/en/userGuide.t2t
Outdated
| ++ 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
@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. |
|
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. |
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. |
user_docs/en/userGuide.t2t
Outdated
|
|
||
| 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 |
There was a problem hiding this comment.
"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.
| - Insecure network connections | |
| - Using unencrypted network connections |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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
| - 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. |
There was a problem hiding this comment.
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.
| - 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. |
There was a problem hiding this comment.
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.
|
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.
Depending on the provided answer, we can figure which information needs to be provided or not and where:
|
|
@Adriani90 You posted a link to Microsoft's description of Microsoft Store permissions. 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. 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. |
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:
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
changed the title
|
@CyrilleB79 wrote:
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.
It is a mix of both. Building awareness is always a mix of basic concepts and recommendations.
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.
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:
I don't think so, it is verylimited and still not enough to build enough awareness.
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. @CyrilleB79 wrote:
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.
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.
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.
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. 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: 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: 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. |
|
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: |
seanbudd
added
blocked/needs-product-decision
|
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. |
|
It seems it has been decided to not implement virus total checks because this would result in too many false positives being detected. |
|
@Adriani90 I think you misread my comment, we intend to use VirusTotal still, unless a problem with false positives arise |
Adriani90
force-pushed
the
SecurityandPrivacyNotes
branch
from
3133208
to
7d61214
Compare
|
@Qchristensen this is now re-drafted in md and ready for another review. |
seanbudd
added
merge-early
…tyandPrivacyNotes # Conflicts: # user_docs/en/userGuide.md
Adriani90
force-pushed
the
SecurityandPrivacyNotes
branch
from
ee00c8c
to
589303e
Compare
|
@SaschaCowley conflicts are fixed, is this still blocked by something? |
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: