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


Well I am not sure what to think.
True a lot of people are taking it like it wasn't anything.
This particular guy and guys like him there are a couple have bitched about nvda remote being unsecure.
Its only a problem if.
1. you give out your key.
2. you autoconnect to things all the time there is no need, this excludes say if you admin something say on a network and you need access, even then, I guess you turn off your access as needed at any rate if you are doing adminning nvda needs to be active to do so so you can still autoconnect when you are running nvda and as long as nvda does not run thats fine, I guess you can turn it off and on as you wish I was planning to set several units with unique keys which ofcause I will not share for those purposes.
3. since the file for the key the .ini is not hidden or encripted anyone can get it, this assumes you give it out in the first place or your friend who is helping you is a total idiot and shares/uses the key for something.
As an added thingy, you can generate your own keys, every time you exit a session if you wish and don't save, those keys are destroyed there is a key generator.
The thing is opensource meaning even if the key was encripted, well you can't protect it as such because of the nature people would find out how.
As far as I understand it, someone says, looky at me I will make a key called 123 and just have people foul my computer.
Now on several hack forums and stuff I visit a lot of people have just done this, like hay, here is a key, see how much you can stuff up my vm and see how good the os is.
Now thats a vm, you can create and destroy that if it gets to dammaged and as long as you don't stupidly externally link it to an entire drive or something, set a folder say for its access then the worse you can do is mangle that and if you are smart you damn sure will make sure its not even important.
A lot of us geeks dammage vms all the time, thats what those are for, testing and seing, otherwise what would we use vms for.
Its a bit stupid to allow your live machine for this treatment, a vm hack fest is fine, if it gets clobbered, make another.
And if you don't want another, make a backup of the image files before we come in and trash it.
5. its not our fault if someone doesn't save data, and all that happened was someone made nvda crash with a lengthy string of junk.
This was all it was.
The reciever had to reboot and his data in memmory which he had not saved was gone.
Nothing was dammaged.
Yet he cries wolf.
Having known tyler from before when he did stupid things I know full well, me being a fellow pirate laughed it off, others didn't think it was funny.
But still, he is now doing good which is fine.
Any bit of software will dammage you if you are stupid.
Ie who posts a key of 123, in fact who posts a password of 123 these days.
I admit on a public service I posted a number of 12345 on a private service becuase I couldn't be bothered with security, but later on when it was upgraded I changed it to another number.
From time to time this guy appears and says something.

On 12/10/2016 3:05 a.m., Mallard wrote:
From the incident description, in my humble opinon, it looks as if the
whole thing had been carefully planned, with the purpose of deliberately
damaging the community and NVDA's reputation.

Unfortunately I've been seeing disruptive behavours on other lists
lately, where some "clever" person(s) faked a group member's account and
started trolling the list.

As Einstein once said, there are only two infinitethings: the Universe
and human stupidity... And there are still doubts about the first one...

I'd say both these incidents, the NVDA Remote and the other one I was
referring to, fall into this category.

Il 11/10/2016 15:46, Jeremy ha scritto:
As I understand it, the individuals who had their remote sessions
tinkered with had basically invited someone to screw with them. Once
it became clear who the group was who had their sessions played with,
or at least some of those in the group were, the whole thing became
kind of entertaining. While the person who sent the playful strings of
text could maybe have made slightly better choices, those individuals
who received said playful strings were apparently trying to figure out
how it was done, so they could use it on others.

had those individuals being messed with not had their own malicious
intent, as I strongly suspect, I don't think it would have ever come
to this. Either way, you try and screw with someone and every now and
then, someone much more intelligent than you comes along and plays
with you a little. That's the way of things on the internet.

Shaun Everiss wrote:
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

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
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,
people connected to the poster's computer, but then the host
disconnected. A
few moments later, the server admin came in using the published
changed some configurations and crashed NVDA by letting clients read
strings and making their keyboards unusable. An audio recording was
published that provides some live evidence, with people posting on
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

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
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

Thank you.




Join to automatically receive all group messages.