Re: 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.