Date   

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

 

Yeah I agree.
I had a laptop with a bios that didn't update and a fan that didn't work and packed it away and it was dead.
Due to heat in summer especially with the humidity in new zealand though other countries and places can get hotter, I have had to put a coolant fan desk under my computer at all times.
In fact during summer especially if my laptop is on my lap which it can be from time to time I have got vary burned legs from just putting it there so yeah.
A friend who has his system in an well ventelated atic room still says that even with his fans full up on his gaming wrig he needs to stick 1 or 2 fans into his case just to cool it down.
He probably needs several heat pumps or something on the other hand the solar panels are in his rough so yeah who knows.
Things can get quite hot.
For myself I have a room with 2 computers, 1 workstation and a small desk server.
It does have 2 sides to open windows but even then well.

On 12/10/2016 9:05 a.m., Jeremy wrote:
Lol, that was really too bad, as I really liked the note line of
devices. Figured it was Samsung's attempt at contributing to some sort
of a bang poppy celebration, but no one seems to appreciate their
version of fireworks.

In all seriousness though, It's not only the note that I've seen that
can get really hot, if put in certain situations. I've seen IPhones that
have gotten hot enough that you could barely touch the glass on the face
of them.
Then again, I've also seen people forget to set their laptops to sleep
or hibernate and then slip it into a case, leading to a pretty decent
smoke out.

Shaun Everiss wrote:
I agree, I reported this in my blog last week.
So many are doing stupid things all the time.
If we need to be worried about anything it is if we have a shiny new
galaxy note bomb or not.
Samsung recalled all gn7s and has canciled production, some sources
say thats the end of the note.
However a expert says as we get better and faster phones they become
more like our computer units, and more powerfull and the energy needs
to go somewhere, they don't have fans, fans would drain battery faster
but the fact is even with flash chips we will need to get our phones
cool somehow.
And since our phones live in cases, etc and we havn't really had the
need to cool them as such that will only become more an issue as it
comes up.



On 12/10/2016 7:41 a.m., Jeremy wrote:
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.
Brian

bglists@...
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: <nvda@nvda.groups.io>
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
nvdaremote.com 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
privately.

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.

Cheers,

Joseph











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

jeremy <icu8it2@...>
 

Lol, that was really too bad, as I really liked the note line of devices. Figured it was Samsung's attempt at contributing to some sort of a bang poppy celebration, but no one seems to appreciate their version of fireworks.

In all seriousness though, It's not only the note that I've seen that can get really hot, if put in certain situations. I've seen IPhones that have gotten hot enough that you could barely touch the glass on the face of them.
Then again, I've also seen people forget to set their laptops to sleep or hibernate and then slip it into a case, leading to a pretty decent smoke out.

Shaun Everiss wrote:

I agree, I reported this in my blog last week.
So many are doing stupid things all the time.
If we need to be worried about anything it is if we have a shiny new galaxy note bomb or not.
Samsung recalled all gn7s and has canciled production, some sources say thats the end of the note.
However a expert says as we get better and faster phones they become more like our computer units, and more powerfull and the energy needs to go somewhere, they don't have fans, fans would drain battery faster but the fact is even with flash chips we will need to get our phones cool somehow.
And since our phones live in cases, etc and we havn't really had the need to cool them as such that will only become more an issue as it comes up.



On 12/10/2016 7:41 a.m., Jeremy wrote:
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.
Brian

bglists@...
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: <nvda@nvda.groups.io>
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
nvdaremote.com 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
privately.

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.

Cheers,

Joseph








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

 

I agree, I reported this in my blog last week.
So many are doing stupid things all the time.
If we need to be worried about anything it is if we have a shiny new galaxy note bomb or not.
Samsung recalled all gn7s and has canciled production, some sources say thats the end of the note.
However a expert says as we get better and faster phones they become more like our computer units, and more powerfull and the energy needs to go somewhere, they don't have fans, fans would drain battery faster but the fact is even with flash chips we will need to get our phones cool somehow.
And since our phones live in cases, etc and we havn't really had the need to cool them as such that will only become more an issue as it comes up.

On 12/10/2016 7:41 a.m., Jeremy wrote:
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.
Brian

bglists@...
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: <nvda@nvda.groups.io>
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
nvdaremote.com 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
privately.

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.

Cheers,

Joseph







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

 

Well it was all for fun.
Sadly, on some forums there is a group that cries over security in remote.
No data was lost just stuff in ram, and stuff in ram is destroyed all the time.
They didn't save, someone crashed nvda and they had to restart.
Maybe someone should find this group and put criptolocker on their systems with instructions that they need to apologise to the rest of us for being idiots, not do it again, and say if they do they will be removed from lists and blacklisted for ever.
Nothing to bad, but this group pops up every so often, they lay low then pop up.
They will probably do that right now.

On 12/10/2016 2:46 a.m., Jeremy wrote:
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
members:



Dear users of NVDA Remote Support add-on:



On the morning of October 10, 2016, a group of users connected via
nvdaremote.com 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
privately.

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.

Cheers,

Joseph




.


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.
4.
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...
(lol).

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




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



Dear users of NVDA Remote Support add-on:



On the morning of October 10, 2016, a group of users connected via
nvdaremote.com 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
privately.

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.

Cheers,

Joseph







.


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

bglists@...
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: <nvda@nvda.groups.io>
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
nvdaremote.com 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
privately.

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.

Cheers,

Joseph




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

jeremy <icu8it2@...>
 

Yeah, that's kind of how it appeared to me too. Main thing I think is important to keep in mind, as has already been said here, don't give out personal information or participate in things that may sound shady, unless you fully know what you're dealing with. It's also worth pointing out, in as much as I understand how it took place, it was mainly the remote server that allowed this to occur, so understand that in most cases, when you make a connection to a server, the admin of that server may be able to do things you may not necessary wish them to.

I personally don't see any issues using nvdaremote.com and for the few times I've used it, it's worked wonderfully, but then I'm not participating in this crap that got all this started either. I do however think that it would be a good idea for better documentation on the installation of the remote server to be placed somewhere, so that people have easier access to run their own, if they wish too.

I think that NVDA remote was an amazing contribution to the community and that Tyler and Tauth did a wonderful job, but I do kind of wish that we could see some updates in it's development. That's for another topic though, me thinks. :)
Take care.

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... (lol).

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




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



Dear users of NVDA Remote Support add-on:



On the morning of October 10, 2016, a group of users connected via
nvdaremote.com 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
privately.

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.

Cheers,

Joseph







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

Brian's Mail list account
 

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

bglists@...
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: <nvda@nvda.groups.io>
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
nvdaremote.com 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
privately.

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.

Cheers,

Joseph


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

Mallard <mallard@...>
 

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... (lol).

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

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



Dear users of NVDA Remote Support add-on:



On the morning of October 10, 2016, a group of users connected via
nvdaremote.com 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
privately.

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.

Cheers,

Joseph





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

jeremy <icu8it2@...>
 

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



Dear users of NVDA Remote Support add-on:



On the morning of October 10, 2016, a group of users connected via
nvdaremote.com 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
privately.

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.

Cheers,

Joseph


Re: Announcing Windows 10 App Essentials 16.10.1

Mário Navarro
 

       


thank you Joseph.

cheers.


Às 05:22 de 11/10/2016, Joseph Lee escreveu:

Hi all,

 

I’m delighted to announce the release of Windows 10 App Essentials add-on 16.10.1. This includes minor tweaks and translation updates. The new add-on and the changelog can be found at:

https://github.com/josephsl/wintenApps/releases/tag/16.10.1

 

Cheers,

Joseph



Re: entering data in Firefox

 

I have seen this in win10 where after putting in a username, nvda does not move to the password field and I have to manually diidle round to get the right field it doesn't happen with v7 of windows.

On 6/10/2016 9:58 p.m., Cearbhall O'Meadhra wrote:
Hi,



Today I tried to log in to our government applications site using NVDA
2016.3 and Firefox 40.0.1 under Windows 10

Here is the url:

https://www.publicjobs.ie/publicjobs/



There are three edit boxes: a search area and then a user name and a
password edit box. Normally, using Firefox, I simply tab to the user name
and press enter to type in the user name. When I went to it this morning,
the edit box sound played as I opened the user name box but I could not type
anything in the box. When I pressed tab to come out of the box, nothing
happened. All I could do was to press escape to bring me back to browse mode
and close the box. I even pressed the sign in button in hopes that I had
entered the user name and password even though I could not monitor that
action, but, again, the button did not react.



I switched over to Internet explorer and pasted in the above url. This time
NVDA reported the usual edit boxes for search user and password and each
opened correctly and echoed my typing. I was able to successfully enter the
user page and continue with my work.



Can anyone explain what has happened to Firefox lately? I am finding this
inertia quite a lot recently. By the way, I have not added anything to
Firefox for the past three months.







All the best,



Cearbhall



m +353 (0)833323487 Ph: _353 (0)1-2864623 e: cearbhall.omeadhra@...








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
nvdaremote.com 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
privately.

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.

Cheers,

Joseph


Re: got locked out of my gmail account in firefox

 

There is sorto of an easier way round this.
There are 3 reasons you can't sign in to gmail.
1. you are in another country trying to access the mail with same credentials.
I have had it where I have signed in and in the same country and it notifies you.
I was trying to help my mum while away and signed into her system, this triggered the security system.
I needed to get a varification from her phone.
After that I had to change her password to one then change it again when she came back.
2. you got hacked.
Once I got someone in my account and it triggered the security system.
However the system grabbed his ip, and other info and this included his isp.
I was able to contact his isp with the information and the issue was handled.
The last time is simply bad luck.
close firefox, and then with ccleaner just clear your junk files and make sure you do your cookies to.
It should then come back.
4. you could have come in when the server was offline it doesn't happen often but it does from time to time.
The only time it was really bad was well when most services just stopped for an hour with no explanation.
It turned out from my isp that a local datacentre had lost one of their storage arrays and all drives in that and had to transfer to the us while they replaced it and then back again.

On 10/10/2016 2:47 a.m., Nevzat Adil wrote:
You'll need to reset your username or password.

On 10/9/16, Brian's Mail list account <bglists@...> wrote:
I think it does this if too many wrong entries are attempted. It used to
allow you back in after a time, but they change stuff every few days over
there, so who really knows.
Brian

bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Rosemarie Chavarria" <knitqueen2007@...>
To: <nvda@nvda.groups.io>
Sent: Saturday, October 08, 2016 10:38 PM
Subject: [nvda] got locked out of my gmail account in firefox


Hi, everyone,


How do I find my gmail account in firefox? I got locked out. What I want
to do si practice using the online gmail site. I just listened to the
tutorial on gmail and it's great but now I'm locked out of my account.


Thanks for your help in advance.


Rosemarie









.


Could somebody confirm this issue before I put it in a ticket?

Brian's Mail list account
 

Internet Explorer 11 latest stable version of nvda. The second checkbox about focus mode changes in the browse mode dialogue, seems to have no effect.
IE in Firefox, changing this effectively allows or stops you scrolling over the edit box but still drops into it when focussed, in IE this gets the cursor, sorry carat stuck in the edit box no matter what the setting for the option is.
I'm using windows 7.
In addition, in snapshots this is still the case, master is exactly the same, but Next generates the error sound whenever it goes into focus mode as well.
Thanks, if others can duplicate at least part of this then I'll make a ticket, if not then I might have some odd problem here.
However I've encountered it on xp clunkers but that is ie8 of course not the current one.
Brian

bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.


Announcing Windows 10 App Essentials 16.10.1

 

Hi all,

 

I’m delighted to announce the release of Windows 10 App Essentials add-on 16.10.1. This includes minor tweaks and translation updates. The new add-on and the changelog can be found at:

https://github.com/josephsl/wintenApps/releases/tag/16.10.1

 

Cheers,

Joseph


Re: keyboard question

Kwork
 


That's good. I'm glad you found it.
Travis

----- Original Message -----
Sent: Monday, October 10, 2016 8:08 PM
Subject: Re: [nvda] keyboard question

    As soon as I wrote that email, I was able to find it.  Thanks everyone for being so patient with me.


On 10/10/2016 11:05 PM, Gene wrote:
It may not be shown in your system tray.  Your system tray may be set to not show all icons that can be shown there.  That's a Windows setting and not a screen-reader setting so you don't have to worry about not knowing about that as an NVDA function.
 
Someone may tell you how to check the system tray setting.  I'll leave that to others.  I've almost never used the setting and others will be far more familiar with it and not have to experiment as I would to figure it out.
 
But here is another way you can set the caps lock as a modifier.
 
I'll also explain that just as FS calls any key used as a modifier to work with JAWS the JAWS key, NVDA developers refer to any key that you use as an NVDA modifier as the NVDA key.  So once you set the caps lock key, it will be an NVDA key.
 
Again, someone can tell you were to find this file.  I don't know where it is in your version of Windows and I am running a portable version of NVDA so it wouldn't  be in the same place as yours anyway.
Once you find the NVDA.ini file, press enter on it.  It will open in Notepad.
There are a lot of settings but if you look far enough, you will fine keyboard settings.
Look for this line:
 useCapsLockAsNVDAModifierKey = false
Change the worde false to true and then save the file with control s.
Close notepad, then close NVDA and run it again.  If you want to reboot to cause NVDA to close and run again, you may.  or you can end the program using the task manager and run it again.
 
Now, you will be able to use the caps lock as an NVDA key.
 
Gene
----- Original Message -----
Sent: Monday, October 10, 2016 9:41 PM
Subject: Re: [nvda] keyboard question

     I did the windows plus B, but I can't find the NVDA setting. So
very sorry for being uninformed about this screenreader.


On 10/10/2016 4:38 PM, Kwork wrote:
> Melissa, if you are not currently able to use the insert key as an NVDA
> modifier key, do the following:
>
> 1. Press windows key plus b to get to the notification area.
> 2. Arrow around till you hear the word "NVDA."
> 3. Press the space bar or the enter key to activate the NVDA menu.
> 4. Arrow down to preferences, then press the right arrow key to open the
> preferences menu.
> 5. Arrow down to Keyboard settings, and press enter to enter the dialog
> where you can tab around to explore the various options.
> 6. Tab till you hear the words "Use CapsLock as an NVDA modifier key."
> 7. Press the spacebar to check it. If it was already check, the spacebar
> will uncheck it. Press it again to make sure it's checked.
> 8. Tab to the ok button and press the spacebar to approve the changes and
> exit the keyboard settings.
> Of course there are other settings you can set while you're in there, so
> look around before exiting.
> I personally have both the insert key and the capps lock set as modifiers.
> Like you, I have heard that many newer keyboards are losing the insert key,
> so having an alternate modifier is important.
> I know that you can also set the keyboard to laptop, but don't know the
> commands there, so have no idea if that'll help you at all or not.
> Good luck,
> Travis
> ----- Original Message -----
> From: "Melissa Galbraith" <wvflutist@...>
> To: <nvda@nvda.groups.io>
> Sent: Monday, October 10, 2016 12:41 PM
> Subject: [nvda] keyboard question
>
>
> I'm using NVDA and am not sure of all the hotkeys.  The keyboards I am
> using don't have the insert key, and I read in an article last night
> that the insert key is being phased out.  Many of the ewer keyboarders
> don't feature it.  How in the world am I supposed to do some of the
> commands with out it.?
>
>
> Melissa
>
>
>
>
>
>
>





Re: keyboard question

Melissa G <wvflutist@...>
 

    As soon as I wrote that email, I was able to find it.  Thanks everyone for being so patient with me.


On 10/10/2016 11:05 PM, Gene wrote:

It may not be shown in your system tray.  Your system tray may be set to not show all icons that can be shown there.  That's a Windows setting and not a screen-reader setting so you don't have to worry about not knowing about that as an NVDA function.
 
Someone may tell you how to check the system tray setting.  I'll leave that to others.  I've almost never used the setting and others will be far more familiar with it and not have to experiment as I would to figure it out.
 
But here is another way you can set the caps lock as a modifier.
 
I'll also explain that just as FS calls any key used as a modifier to work with JAWS the JAWS key, NVDA developers refer to any key that you use as an NVDA modifier as the NVDA key.  So once you set the caps lock key, it will be an NVDA key.
 
Again, someone can tell you were to find this file.  I don't know where it is in your version of Windows and I am running a portable version of NVDA so it wouldn't  be in the same place as yours anyway.
Once you find the NVDA.ini file, press enter on it.  It will open in Notepad.
There are a lot of settings but if you look far enough, you will fine keyboard settings.
Look for this line:
 useCapsLockAsNVDAModifierKey = false
Change the worde false to true and then save the file with control s.
Close notepad, then close NVDA and run it again.  If you want to reboot to cause NVDA to close and run again, you may.  or you can end the program using the task manager and run it again.
 
Now, you will be able to use the caps lock as an NVDA key.
 
Gene
----- Original Message -----
Sent: Monday, October 10, 2016 9:41 PM
Subject: Re: [nvda] keyboard question

     I did the windows plus B, but I can't find the NVDA setting. So
very sorry for being uninformed about this screenreader.


On 10/10/2016 4:38 PM, Kwork wrote:
> Melissa, if you are not currently able to use the insert key as an NVDA
> modifier key, do the following:
>
> 1. Press windows key plus b to get to the notification area.
> 2. Arrow around till you hear the word "NVDA."
> 3. Press the space bar or the enter key to activate the NVDA menu.
> 4. Arrow down to preferences, then press the right arrow key to open the
> preferences menu.
> 5. Arrow down to Keyboard settings, and press enter to enter the dialog
> where you can tab around to explore the various options.
> 6. Tab till you hear the words "Use CapsLock as an NVDA modifier key."
> 7. Press the spacebar to check it. If it was already check, the spacebar
> will uncheck it. Press it again to make sure it's checked.
> 8. Tab to the ok button and press the spacebar to approve the changes and
> exit the keyboard settings.
> Of course there are other settings you can set while you're in there, so
> look around before exiting.
> I personally have both the insert key and the capps lock set as modifiers.
> Like you, I have heard that many newer keyboards are losing the insert key,
> so having an alternate modifier is important.
> I know that you can also set the keyboard to laptop, but don't know the
> commands there, so have no idea if that'll help you at all or not.
> Good luck,
> Travis
> ----- Original Message -----
> From: "Melissa Galbraith" <wvflutist@...>
> To: <nvda@nvda.groups.io>
> Sent: Monday, October 10, 2016 12:41 PM
> Subject: [nvda] keyboard question
>
>
> I'm using NVDA and am not sure of all the hotkeys.  The keyboards I am
> using don't have the insert key, and I read in an article last night
> that the insert key is being phased out.  Many of the ewer keyboarders
> don't feature it.  How in the world am I supposed to do some of the
> commands with out it.?
>
>
> Melissa
>
>
>
>
>
>
>





Re: keyboard question

Gene
 

It may not be shown in your system tray.  Your system tray may be set to not show all icons that can be shown there.  That's a Windows setting and not a screen-reader setting so you don't have to worry about not knowing about that as an NVDA function.
 
Someone may tell you how to check the system tray setting.  I'll leave that to others.  I've almost never used the setting and others will be far more familiar with it and not have to experiment as I would to figure it out.
 
But here is another way you can set the caps lock as a modifier.
 
I'll also explain that just as FS calls any key used as a modifier to work with JAWS the JAWS key, NVDA developers refer to any key that you use as an NVDA modifier as the NVDA key.  So once you set the caps lock key, it will be an NVDA key.
 
Again, someone can tell you were to find this file.  I don't know where it is in your version of Windows and I am running a portable version of NVDA so it wouldn't  be in the same place as yours anyway.
Once you find the NVDA.ini file, press enter on it.  It will open in Notepad.
There are a lot of settings but if you look far enough, you will fine keyboard settings.
Look for this line:
 useCapsLockAsNVDAModifierKey = false
Change the worde false to true and then save the file with control s.
Close notepad, then close NVDA and run it again.  If you want to reboot to cause NVDA to close and run again, you may.  or you can end the program using the task manager and run it again.
 
Now, you will be able to use the caps lock as an NVDA key.
 
Gene

----- Original Message -----
Sent: Monday, October 10, 2016 9:41 PM
Subject: Re: [nvda] keyboard question

     I did the windows plus B, but I can't find the NVDA setting. So
very sorry for being uninformed about this screenreader.


On 10/10/2016 4:38 PM, Kwork wrote:
> Melissa, if you are not currently able to use the insert key as an NVDA
> modifier key, do the following:
>
> 1. Press windows key plus b to get to the notification area.
> 2. Arrow around till you hear the word "NVDA."
> 3. Press the space bar or the enter key to activate the NVDA menu.
> 4. Arrow down to preferences, then press the right arrow key to open the
> preferences menu.
> 5. Arrow down to Keyboard settings, and press enter to enter the dialog
> where you can tab around to explore the various options.
> 6. Tab till you hear the words "Use CapsLock as an NVDA modifier key."
> 7. Press the spacebar to check it. If it was already check, the spacebar
> will uncheck it. Press it again to make sure it's checked.
> 8. Tab to the ok button and press the spacebar to approve the changes and
> exit the keyboard settings.
> Of course there are other settings you can set while you're in there, so
> look around before exiting.
> I personally have both the insert key and the capps lock set as modifiers.
> Like you, I have heard that many newer keyboards are losing the insert key,
> so having an alternate modifier is important.
> I know that you can also set the keyboard to laptop, but don't know the
> commands there, so have no idea if that'll help you at all or not.
> Good luck,
> Travis
> ----- Original Message -----
> From: "Melissa Galbraith" <wvflutist@...>
> To: <nvda@nvda.groups.io>
> Sent: Monday, October 10, 2016 12:41 PM
> Subject: [nvda] keyboard question
>
>
> I'm using NVDA and am not sure of all the hotkeys.  The keyboards I am
> using don't have the insert key, and I read in an article last night
> that the insert key is being phased out.  Many of the ewer keyboarders
> don't feature it.  How in the world am I supposed to do some of the
> commands with out it.?
>
>
> Melissa
>
>
>
>
>
>
>




Re: keyboard question

Aravind R
 

after pressing windows+b, press space bar then press arrow keys. you
will find nvda on overflow area. you can activate by pressing enter
and reach nvda settings.

On 10/11/16, Melissa Galbraith <wvflutist@...> wrote:
I did the windows plus B, but I can't find the NVDA setting. So
very sorry for being uninformed about this screenreader.


On 10/10/2016 4:38 PM, Kwork wrote:
Melissa, if you are not currently able to use the insert key as an NVDA
modifier key, do the following:

1. Press windows key plus b to get to the notification area.
2. Arrow around till you hear the word "NVDA."
3. Press the space bar or the enter key to activate the NVDA menu.
4. Arrow down to preferences, then press the right arrow key to open the
preferences menu.
5. Arrow down to Keyboard settings, and press enter to enter the dialog
where you can tab around to explore the various options.
6. Tab till you hear the words "Use CapsLock as an NVDA modifier key."
7. Press the spacebar to check it. If it was already check, the spacebar
will uncheck it. Press it again to make sure it's checked.
8. Tab to the ok button and press the spacebar to approve the changes and
exit the keyboard settings.
Of course there are other settings you can set while you're in there, so
look around before exiting.
I personally have both the insert key and the capps lock set as
modifiers.
Like you, I have heard that many newer keyboards are losing the insert
key,
so having an alternate modifier is important.
I know that you can also set the keyboard to laptop, but don't know the
commands there, so have no idea if that'll help you at all or not.
Good luck,
Travis
----- Original Message -----
From: "Melissa Galbraith" <wvflutist@...>
To: <nvda@nvda.groups.io>
Sent: Monday, October 10, 2016 12:41 PM
Subject: [nvda] keyboard question


I'm using NVDA and am not sure of all the hotkeys. The keyboards I am
using don't have the insert key, and I read in an article last night
that the insert key is being phased out. Many of the ewer keyboarders
don't feature it. How in the world am I supposed to do some of the
commands with out it.?


Melissa









--
nothing is difficult unless you make it appear so.

r. aravind,

Assistant manager
Department of sales
bank of baroda retail loan factory, Chennai.
mobile no: +91 9940369593, 9710945613.
email id : aravind_069@..., aravind.andhrabank@....

91601 - 91620 of 101113