Re: NVDA Remote crash incident: trust and ethics are important just as technology is, never give out passwords publicly, developer responsibilities

jeremy <icu8it2@...>

It kind of reminds me of the thing going around about the headphone jack on the newer IPhone 7s. Apparently one can take a drill to the bottom of their pretty new device and if you've got the placement just right, you can reveal a hidden jack.

I find it absolutely crazy how many people apparently have fallen for this crap and caused serious problems to brand new IPhones, just because they seen it on youtube or facebook. While I feel bad that people fall for things like this, it still makes me scratch my noggin in amazement.
Take care.

Brian's Mail list account wrote:

Yes its like when these folk ring you up pretending you have a virus, and asking you to do a remote desktop or some other control your machine from afar program. You just do not do it or give them any secret key you have to get into it on your machine.
I think one can only go so far with protection, some people need to be made aware that its perfectly possible to invite trouble and that passwords were created for a reason.

As an aside there is also a rumour going on on sighted forums that a file associated with dropbox is some kind of malware and even goes into details of how to remove it.
Dbxcon or some such name. the only evidence people are using is that its not actually signed by dropbox but another name. However If you remove all copies it will completely screw up your access to dropbox, so don't take any notice of such things unless they can be absolutely validated by a reputable organisation.
There is far too much misinformation and nasty people about as it is without spreading paranoia about other software.

Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
----- Original Message ----- From: "Shaun Everiss" <sm.everiss@...>
To: <>
Sent: Tuesday, October 11, 2016 11:34 AM
Subject: Re: [nvda] NVDA Remote crash incident: trust and ethics are important just as technology is, never give out passwords publicly, developer responsibilities

I read this to joseph.
1. yeah someone gave his public key which is basically giving his userid and password.
The user got his nvda crashed and lost data in ram, which for some stupid reason he hadn't even save.
It was all mindless fun and just users mucking round.
Sadly the same user has gone over the fact that the main dev criss is not responding to feadback and not hiding the public key, etc, etc.
He then decided to post on a public forum complaining about nv remote in general not being secure.
This same user has done this drama before.
He got what he deserved is all I am saying.

You shouldn't give out your security info.

On 11/10/2016 8:40 a.m., Joseph Lee wrote:
Dear NVDA community:

I give you permission to pass out the following to other community members:

Dear users of NVDA Remote Support add-on:

On the morning of October 10, 2016, a group of users connected via experienced a general client crash, with the root of the
problem being a series of events that led to NVDA crashing with long strings
passed to a particular synthesizer. The event unfolded as follows:

In the evening of October 9, 2016, someone posted a message to a public
forum which included giving out his remote client password, with an
"invitation" for anyone to connect to his computer. Within moments, several
people connected to the poster's computer, but then the host disconnected. A
few moments later, the server admin came in using the published password,
changed some configurations and crashed NVDA by letting clients read long
strings and making their keyboards unusable. An audio recording was
published that provides some live evidence, with people posting on social
media advising others to stop using this, labeling this as "unsecure".

In light of this incident, as a community add-ons representative, I'd like
to request that add-on users follow these guidelines:

1. Never give out NVDA remote session password publicly.

2. The Remote host must provide the password and this should be done

3. The Remote client must tell host what he or she is going to do so
the host can be aware of what's going on.

4. The host should try to inform clients that he or she is
disconnecting so clients can disconnect properly.

Also, as an add-on developer, I'd like to propose the following action plan
in the future:

1. Please examine evidence you can find before coming to the conclusion
that things are insecure.

2. Developers should provide responses as soon as possible when
evidence becomes available.

The add-on can be found in our NVDA Community Add-ons website. Although
there is some things about this add-on that have contributed to this
incident, the ultimate root cause has to do with irresponsible user actions.

Thank you.



Join to automatically receive all group messages.