NVAccess and the slow Erosion of trust: I still believe that NVDA is the best available screen reader, and I still donate monthly.
-
@fastfinge So start them. If you want to answer questions, in addition to asking them.
@cachondo @NVAccess -
@fastfinge So start them. If you want to answer questions, in addition to asking them.
@cachondo @NVAccess@prism @cachondo @NVAccess Seems a bit late to discuss decisions that were already made…somewhere…by someone. Compare to the Linux kernel mailing list. If I want to know what was decided, who decided it, why they decided it, when and where, all discussion is right there. NVDA also operated this way up until the last couple years. When Michael or Jamie decided anything, the reasoning was all in public. Even if I didn’t like it, the chain of thought that got them there was fully visible. -
@prism @fastfinge @cachondo Thank you. And yes, I have spent the last hour or so on this thread, and I haven't even got to half the article yet. So this HAS cost the organisation my time in doing this, when I suspect most of it could have been resolved just by asking a couple of questions first. And just to be clear, asking questions is perfectly fine. It's where they are done as public accusations of poor behaviour without first having obtained the facts that it gets frustrating
@NVAccess @prism @cachondo And that can only happen when the facts aren’t already public. For an open source foundation, that is a problem in and of itself. However, I apologize for wasting your time. In future, I’ll be sure to waste just as much of your time asking questions that should have had public answers when the pull requests were first opened. -
@prism @cachondo @NVAccess Seems a bit late to discuss decisions that were already made…somewhere…by someone. Compare to the Linux kernel mailing list. If I want to know what was decided, who decided it, why they decided it, when and where, all discussion is right there. NVDA also operated this way up until the last couple years. When Michael or Jamie decided anything, the reasoning was all in public. Even if I didn’t like it, the chain of thought that got them there was fully visible.
@fastfinge @cachondo @prism As Drew suggested, what do you want to know? I'm only halfway through your article and most of it is "I don't like this feature, it shouldn't have taken developer time" when, if you'd asked, we could have told you that things like Remote Access, Image Description, Magnifier, etc you complain about - were all done by others and only overseen by us
-
@NVAccess @prism @cachondo And that can only happen when the facts aren’t already public. For an open source foundation, that is a problem in and of itself. However, I apologize for wasting your time. In future, I’ll be sure to waste just as much of your time asking questions that should have had public answers when the pull requests were first opened.
@fastfinge @cachondo @prism But the decisions about <insert feature here> were made <gestures vaguely>. At this point, I do appreciate the passion you have, and I am honestly trying to work with you.... but I don't even know what you are mad about anymore?
-
@fastfinge @cachondo @prism As Drew suggested, what do you want to know? I'm only halfway through your article and most of it is "I don't like this feature, it shouldn't have taken developer time" when, if you'd asked, we could have told you that things like Remote Access, Image Description, Magnifier, etc you complain about - were all done by others and only overseen by us
@NVAccess @cachondo @prism If you have understood that to be my primary complaint, I must have written it extremely poorly. Because developer time was never even mentioned once. My complaint is that things seem to be going into NVDA without openly accessible discussion or reasoning about the trade offs. So: Why is NVDA scanning store addons with virustotal? What threat does NV Access believe this prevents, given the overall addon security landscape? What does NVAccess believe is the purpose of addons, and when should an addon be in core vs. Not? Are there types of addons that NVDA does not believe are suitable, and should just be apps on their own? What qualifies a feature for an addon vs. Being part of NVDA? How are decisions made at NV Access, now that they aren’t as frequently discussed on the GitHub or the mailing list? How should external stakeholders get involved in these decisions? Speaking of those decisions: what is the current thinking RE: the 32-bit compatibility layer? Has this been canceled as it’s no longer needed? What is the current thinking on the secure addon API? Are we talking about extremely restricted functionality, or code signing, or manual approval of secure addons, or all three? Where can we see, developers work opt planning (if any) being done on corporate mode? Surely there’s something other than “no news” on an issue tracker or mailing list somewhere. I’m avoiding “Why did you do X last year” style questions, as re-litigation of things already done is utterly pointless. But these are the current questions that I am most concerned about. -
@NVAccess @prism @cachondo And that can only happen when the facts aren’t already public. For an open source foundation, that is a problem in and of itself. However, I apologize for wasting your time. In future, I’ll be sure to waste just as much of your time asking questions that should have had public answers when the pull requests were first opened.
Ok just to satisfy you that it isn't only my time you've taken up this morning, but our other staff who also tried to work through your post, here is a comment from one of our developers:
Also I don't understand why he thinks this stuff was not discussed.
https://github.com/nvaccess/nvda/discussions/19462
https://github.com/nvaccess/nvda/discussions/19807
https://github.com/nvaccess/nvda/discussions/14912
https://github.com/nvaccess/nvda/discussions/16304and a lot of the discussion can be found from the issues/PRs linked in the change log
-
@fastfinge @cachondo @prism But the decisions about <insert feature here> were made <gestures vaguely>. At this point, I do appreciate the passion you have, and I am honestly trying to work with you.... but I don't even know what you are mad about anymore?
@NVAccess @cachondo @prism I’m not mad at all. I’m concerned. Deeply. But that’s far from anger. And I also find it strange that you seem to think my entire purpose is to waste as much developer time as possible, and would be gleeful the more of your time I can manage to take up. I’m so baffled by that assumption thatI’m starting to wonder if your mental model of me as a person is just so far off that mutual communication or understanding is even possible. -
@NVAccess @cachondo @prism If you have understood that to be my primary complaint, I must have written it extremely poorly. Because developer time was never even mentioned once. My complaint is that things seem to be going into NVDA without openly accessible discussion or reasoning about the trade offs. So: Why is NVDA scanning store addons with virustotal? What threat does NV Access believe this prevents, given the overall addon security landscape? What does NVAccess believe is the purpose of addons, and when should an addon be in core vs. Not? Are there types of addons that NVDA does not believe are suitable, and should just be apps on their own? What qualifies a feature for an addon vs. Being part of NVDA? How are decisions made at NV Access, now that they aren’t as frequently discussed on the GitHub or the mailing list? How should external stakeholders get involved in these decisions? Speaking of those decisions: what is the current thinking RE: the 32-bit compatibility layer? Has this been canceled as it’s no longer needed? What is the current thinking on the secure addon API? Are we talking about extremely restricted functionality, or code signing, or manual approval of secure addons, or all three? Where can we see, developers work opt planning (if any) being done on corporate mode? Surely there’s something other than “no news” on an issue tracker or mailing list somewhere. I’m avoiding “Why did you do X last year” style questions, as re-litigation of things already done is utterly pointless. But these are the current questions that I am most concerned about.
@fastfinge @cachondo @prism Ok if nothing else, I can no longer complain that you haven't asked us questions.... I'm confused about the hate on VirusTotal? It's a tool which may pick up malicious code that is available, so why NOT use it? Add-on vs core for a feature is done case by case (based on user benefit, potential downsides, initial vs ongoing work, & more. For remote, as previously noted, it also allowed us to tighten security by bringing those external contact points internal
-
Ok just to satisfy you that it isn't only my time you've taken up this morning, but our other staff who also tried to work through your post, here is a comment from one of our developers:
Also I don't understand why he thinks this stuff was not discussed.
https://github.com/nvaccess/nvda/discussions/19462
https://github.com/nvaccess/nvda/discussions/19807
https://github.com/nvaccess/nvda/discussions/14912
https://github.com/nvaccess/nvda/discussions/16304and a lot of the discussion can be found from the issues/PRs linked in the change log
@NVAccess @cachondo @prism I did find some of these. But a lot of them seem to be discussions of how to do something that has already been decided would be done. Not of the what to do or why to do it. And those discussions are the majority of my concern. However, I could be mistaken, and I will certainly read the links more closely. -
@NVAccess @cachondo @prism I’m not mad at all. I’m concerned. Deeply. But that’s far from anger. And I also find it strange that you seem to think my entire purpose is to waste as much developer time as possible, and would be gleeful the more of your time I can manage to take up. I’m so baffled by that assumption thatI’m starting to wonder if your mental model of me as a person is just so far off that mutual communication or understanding is even possible.
@fastfinge @cachondo @prism Not at all, I was just concerned that you spent a LOT of time writing up incorrect assumptions which could easily have been corrected by either asking, or more fully reading discussions on github etc.
-
@fastfinge @cachondo @prism Ok if nothing else, I can no longer complain that you haven't asked us questions.... I'm confused about the hate on VirusTotal? It's a tool which may pick up malicious code that is available, so why NOT use it? Add-on vs core for a feature is done case by case (based on user benefit, potential downsides, initial vs ongoing work, & more. For remote, as previously noted, it also allowed us to tighten security by bringing those external contact points internal
@NVAccess @cachondo @prism The hate isn’t the service itself. It’s that the results are being displayed in the store. I believe that this is false reassurance, that makes everyone less secure just by existing. Best case, it will always return nothing, because no attacker would upload a virus directly to the store; they’ll have their addon download the virus days later, once it’s gotten some installs. Worst case, it makes someone think “Oh, NVDA virus scans its addons. So they’re fine.” Given the best case is nothing happens, and the worst case is someone is less secure, why do it? What problem is NVAccess trying to solve? -
@fastfinge @cachondo @prism Not at all, I was just concerned that you spent a LOT of time writing up incorrect assumptions which could easily have been corrected by either asking, or more fully reading discussions on github etc.
-
@NVAccess @cachondo @prism The hate isn’t the service itself. It’s that the results are being displayed in the store. I believe that this is false reassurance, that makes everyone less secure just by existing. Best case, it will always return nothing, because no attacker would upload a virus directly to the store; they’ll have their addon download the virus days later, once it’s gotten some installs. Worst case, it makes someone think “Oh, NVDA virus scans its addons. So they’re fine.” Given the best case is nothing happens, and the worst case is someone is less secure, why do it? What problem is NVAccess trying to solve?
@fastfinge @cachondo @prism What do you propose? At the end of the day, add-ons are potentially a risk & I think we are clear in warning users about that. If a bad add-on has to download code days later to avoid detection, at least we've made it harder for them. The add-on community itself keeps an eye on add-ons & would hopefully quite quickly alert us to any issue such as this. The alternative would be extremely tightly restricting what add-ons could do - maybe to Braille drivers & synths?
-
@fastfinge @cachondo @prism What do you propose? At the end of the day, add-ons are potentially a risk & I think we are clear in warning users about that. If a bad add-on has to download code days later to avoid detection, at least we've made it harder for them. The add-on community itself keeps an eye on add-ons & would hopefully quite quickly alert us to any issue such as this. The alternative would be extremely tightly restricting what add-ons could do - maybe to Braille drivers & synths?
@NVAccess @cachondo @prism Well, I would first propose not doing something “because the service exists and we can”. This was the kind of thinking I tried, and seem to have failed, to hilight in the article. Next, I would propose not getting stuck in an either or mindset. The duality of “we do nothing” or “we restrict all addons forever” is a false one.What about tracking reputation of addon authors and making sure that, at least, NV Access can guarantee that the author of an addon is who they say they are. Then making it extremely clear to users who they’re trusting and how much trust they’re handing over. What about having a set of “reviewed addons” and then a set of “unreviewed addons” and listing them in different places, with different levels of warning, and different corporate controls? What about some sort of sandboxing, and prompting the user “Do you want to allow this addon to X?” Where X is dangerous things like download and execute a third party program, read and write files outside of the addon directory, and so on. There are all sorts of possible solutions, some easier, and some harder, that would actually do something other than “Maybe inconvenience an attacker who knows nothing about NVDA Store security someday”. -
@NVAccess @cachondo @prism Well, I would first propose not doing something “because the service exists and we can”. This was the kind of thinking I tried, and seem to have failed, to hilight in the article. Next, I would propose not getting stuck in an either or mindset. The duality of “we do nothing” or “we restrict all addons forever” is a false one.What about tracking reputation of addon authors and making sure that, at least, NV Access can guarantee that the author of an addon is who they say they are. Then making it extremely clear to users who they’re trusting and how much trust they’re handing over. What about having a set of “reviewed addons” and then a set of “unreviewed addons” and listing them in different places, with different levels of warning, and different corporate controls? What about some sort of sandboxing, and prompting the user “Do you want to allow this addon to X?” Where X is dangerous things like download and execute a third party program, read and write files outside of the addon directory, and so on. There are all sorts of possible solutions, some easier, and some harder, that would actually do something other than “Maybe inconvenience an attacker who knows nothing about NVDA Store security someday”.@NVAccess @cachondo @prism Second reply to publicly call myself out for doing exactly the thing I’m annoyed about. I just proposed a raft of solutions without taking the time to fully understand the problem I’m solving for. Is the security problem:
* NVDA needs to work with addons in sensitive enterprise environments
* users need to be able to confidently install addons from the addon store without worrying
* users need to be able to install random addons from the internet with at least some safety
* security people need to be able to audit what an addon is doing
* something else
* all of the above
The best solution is going to depend on what the problem is, and what the available resources are for solving it.I shouldn’t have offered any solutions at all without understanding the shape of the problem. Because otherwise we’re just doing things because we feel like things should be done. Leading me to another question: does NVAccess clearly define what its problems are before it starts planning solutions to them? Or do planning and roadmaps start from the solution, rather than the problem to be solved? Because starting from the solution leads to decisions like scanning addons with an antivirus because it exists and you can. -
Ok just to satisfy you that it isn't only my time you've taken up this morning, but our other staff who also tried to work through your post, here is a comment from one of our developers:
Also I don't understand why he thinks this stuff was not discussed.
https://github.com/nvaccess/nvda/discussions/19462
https://github.com/nvaccess/nvda/discussions/19807
https://github.com/nvaccess/nvda/discussions/14912
https://github.com/nvaccess/nvda/discussions/16304and a lot of the discussion can be found from the issues/PRs linked in the change log
@NVAccess @cachondo @prism And let's get into it:
* NVDA Magnifier available for early testing and feedback: This presents a fait accompli. It doesn't answer questions like "Why did NV Access decide to do this? Why now? Why part of NVDA and not a separate app?" Yes, I realize someone else is doing the initial work. But NV Access still needs to review it, merge it, maintain it, and so on. Just because someone does a thing doesn't mean it's in the project scope. I've refused fully formed pull requests for being out of scope. I'm sure NV Access has, too.
* AI Image descriptions progress: once again, discussion of a thing that's already happening. Not a discussion of why it's happening, or why it was done as part of core and not an addon, and no record of the reasoning and discussion behind the decision. This answers none of the questions I asked.
* Add-on store discussion: this, and the pr linked from it, get way closer to the sort of thing I'm looking for, and the sort of thing I saw all the time from NVAccess in the 2010's and early 2020's, but see much less of now. We get some insight into the thinking. Though we still don't get insight into why NVDA wanted to control the source of addons, and not leave it to the Spanish community, or discussion of the proes and cons of changing the review process for addon developers and how that decision was achieved.
* [Project] Convert NVDA to 64 bit #16304: And right here, we see the user story "Create a 32bit backwards compatible API for synth drivers and braille displays". With a five day final estimate. What happened here? Is this still happening? I did try to find out before I wrote anything at all. It remained unclear. So I'm still in a state where NV Access said a thing was going to happen, the thing did not happen, and I can't tell why or if it will happen later or never. -
@NVAccess @cachondo @prism And let's get into it:
* NVDA Magnifier available for early testing and feedback: This presents a fait accompli. It doesn't answer questions like "Why did NV Access decide to do this? Why now? Why part of NVDA and not a separate app?" Yes, I realize someone else is doing the initial work. But NV Access still needs to review it, merge it, maintain it, and so on. Just because someone does a thing doesn't mean it's in the project scope. I've refused fully formed pull requests for being out of scope. I'm sure NV Access has, too.
* AI Image descriptions progress: once again, discussion of a thing that's already happening. Not a discussion of why it's happening, or why it was done as part of core and not an addon, and no record of the reasoning and discussion behind the decision. This answers none of the questions I asked.
* Add-on store discussion: this, and the pr linked from it, get way closer to the sort of thing I'm looking for, and the sort of thing I saw all the time from NVAccess in the 2010's and early 2020's, but see much less of now. We get some insight into the thinking. Though we still don't get insight into why NVDA wanted to control the source of addons, and not leave it to the Spanish community, or discussion of the proes and cons of changing the review process for addon developers and how that decision was achieved.
* [Project] Convert NVDA to 64 bit #16304: And right here, we see the user story "Create a 32bit backwards compatible API for synth drivers and braille displays". With a five day final estimate. What happened here? Is this still happening? I did try to find out before I wrote anything at all. It remained unclear. So I'm still in a state where NV Access said a thing was going to happen, the thing did not happen, and I can't tell why or if it will happen later or never.@fastfinge @cachondo @NVAccess @prism this is very clearly an emotional conversation where both parties are wrong.
Samuel is a confused user who wrote what reads like a frustrated takedown piece, having hit a straw that broke the camel’s back moment in perceived lack of transparency.
NVAcess doesn’t have a public relations person, but its account that relates to the public is doing that job in a defensive stance.
You guys should kiss and make up.
You’re also kind of both right. Let’s look at the magnifier, since I consider myself an expert user of Windows Magnifier and ZoomIt:
There was no back room decision, it’s all very transparent. Here’s the GitHub issue where it was discussed:
Allow Windows Magnifier to follow NVDA virtual cursor · Issue #12539 · nvaccess/nvda
Is your feature request related to a problem? Please describe. As a visually impaired person, I am using NVDA in conjunction with Windows Magnifier. That works quite smoothly in applications such as Windows Explorer or text editors, sinc...
GitHub (github.com)
A low vision user reported that Windows Magnifier was not following the NVDA virtual cursor.
My instant thought? No big deal, Magnifier can already follow keyboard focus, just have an option to move to mouse to the virtual cursor all the time and leverage the existing tool.
There was a discussion on the Windows Magnifier to Narrator private APIs and then the decision was make to add a magnifier solution to NVDA.
About a year later an add-on author said they’d addressed this issue by moving the mouse cursor and only had a pending problem with tabbing. They were advised the team was already working on a magnifier, but that they could open a PR for this issue.
The issue was ultimately closed by the PR that introduced the magnifier implementation.
This was discussed, decided and implemented completely in the open, and prioritized in a very surprising way.
“I can’t keep my pants up with this belt.”
“We’ll make you a new pair of pants.”
“I have this hole punch I used to tighten my belt.”
“We’re already making the new pants.”There are valid criticisms to make here, but they had their time and place: that issue.
I know a lot of people have accessibility and other issues with GitHub, but that is where this FOSS project is developed and that’s where enthusiastic community members should contribute. I also know there have been discussions about how to make that process more approachable for more people. That’s good, keep doing that.
Just my two cents. I hope this can put things into perspective for you guys and turn this to a more productive direction.
-
@fastfinge @cachondo @NVAccess @prism this is very clearly an emotional conversation where both parties are wrong.
Samuel is a confused user who wrote what reads like a frustrated takedown piece, having hit a straw that broke the camel’s back moment in perceived lack of transparency.
NVAcess doesn’t have a public relations person, but its account that relates to the public is doing that job in a defensive stance.
You guys should kiss and make up.
You’re also kind of both right. Let’s look at the magnifier, since I consider myself an expert user of Windows Magnifier and ZoomIt:
There was no back room decision, it’s all very transparent. Here’s the GitHub issue where it was discussed:
Allow Windows Magnifier to follow NVDA virtual cursor · Issue #12539 · nvaccess/nvda
Is your feature request related to a problem? Please describe. As a visually impaired person, I am using NVDA in conjunction with Windows Magnifier. That works quite smoothly in applications such as Windows Explorer or text editors, sinc...
GitHub (github.com)
A low vision user reported that Windows Magnifier was not following the NVDA virtual cursor.
My instant thought? No big deal, Magnifier can already follow keyboard focus, just have an option to move to mouse to the virtual cursor all the time and leverage the existing tool.
There was a discussion on the Windows Magnifier to Narrator private APIs and then the decision was make to add a magnifier solution to NVDA.
About a year later an add-on author said they’d addressed this issue by moving the mouse cursor and only had a pending problem with tabbing. They were advised the team was already working on a magnifier, but that they could open a PR for this issue.
The issue was ultimately closed by the PR that introduced the magnifier implementation.
This was discussed, decided and implemented completely in the open, and prioritized in a very surprising way.
“I can’t keep my pants up with this belt.”
“We’ll make you a new pair of pants.”
“I have this hole punch I used to tighten my belt.”
“We’re already making the new pants.”There are valid criticisms to make here, but they had their time and place: that issue.
I know a lot of people have accessibility and other issues with GitHub, but that is where this FOSS project is developed and that’s where enthusiastic community members should contribute. I also know there have been discussions about how to make that process more approachable for more people. That’s good, keep doing that.
Just my two cents. I hope this can put things into perspective for you guys and turn this to a more productive direction.
@MostlyBlindGamer @fastfinge @cachondo @prism Always happy to acknowledge where I can do better, and I must admit, logging on to a flood of messages and a 6,000+ word essay attacking us, most of which was not accurate, it was difficult to know where to start. In any case, I definitely don't have any animosity to Sam. Indeed, I appreciate Sam's passion and enthusiasm. Albeit it was a bit .... overwhelming all at once
-
@MostlyBlindGamer @fastfinge @cachondo @prism Always happy to acknowledge where I can do better, and I must admit, logging on to a flood of messages and a 6,000+ word essay attacking us, most of which was not accurate, it was difficult to know where to start. In any case, I definitely don't have any animosity to Sam. Indeed, I appreciate Sam's passion and enthusiasm. Albeit it was a bit .... overwhelming all at once
@NVAccess @MostlyBlindGamer @cachondo @prism I’ve been using and watching NVDA since back in the source forge days. And the change in the decision making still feels obvious to me. The magnifier issue unearthed adds to the point I’m making, not detracts from it. There was no central strategy thought behind it. It just sort of happened. It’s also alarming that any public criticism, no matter how frequently couched in my love and respect for NVDA, is an “attack” that must be “defended” against. I’ll sign off this thread by saying that framing criticism as a battle with winners and losers makes healthy and productive discourse impossible. -
R relay@relay.infosec.exchange shared this topic
