Repository: nvaccess/nvda

Issue:
Add the ability to completely disable NVDA's logging (including NVDA's crash dumps)
### Paths:
1. NVDA menu » Preferences » Settings... » General
2. C:\Users\[Username\AppData\Local\Temp
### Actual behaviour:
At the moment there isn't any way to completely disable NVDA's logging via the GUI which cause security and privacy issues in some circumstances.
### Expected behaviour:
Add a new logging level called "No logging" to the combobox "Logging level". This will also disable creating the files "nvda_crash.dmp" and "nvda-old.log" in the user temp folder during a NVDA crash as well.
### System configuration:
#### NVDA version:
2018.1 (and earlier) to 2018.2.1


Discussion:
Hi,

2018 GDPR...

Can you tell us one or two compelling justifications other than closing security and privacy hole as to why this should be done?

Thanks.
Hi,

I should have said, "one or two additional justifications other than closing security and privacy hole". Thanks.
If the bluetooth name of a braille display contains personal data like the name of the owner and this information is logged by NVDA data, then of course it effects the GDPR. Because maybe someone wants to connect his braille display to a –let's say – public PC or to an non-trustable PC, the owner of those PCs could find out the real name of the owner of the braille display, even if he didn't want that.

Well, and what does the NVDA crash dump files exactly contains? I couldn't find any information about this in the NVDA user guide as well as in [this](https://github.com/nvaccess/nvda/wiki/LogFilesAndCrashDumps) and [this wiki article](https://github.com/nvaccess/nvda/wiki/Debugging-crashes).

So the question should be: Why does a normal user needs to be logged by NVDA – even if the logging level is set to "Information"? And the crash dump is only useful for debugging. So in other words: If a developer isn't asking for that, why is it created be default?

And one more question: Does NVDA read anything from the logfile during running?
Hi,

Bluetooth device name: as far as I knw (I'm sure @LeonardDer have more accurate info), NVDA doesn't care which bluetooth device it is connected to as long as it can be located easily (using a ID format I believe). For example, when I change my BrailleNote Apex's device name to my name, NVDA will still find it.

Regarding crash dump content: it contains things such as active memory set (mostly virtual memory), values of CPU registers, stack traces and what not.

As for NVDA being able to read from log: no, it can't (users can) unless a malicious actor comes along and queries where NVDA stores logs through inspecting address space of nvda.exe (via another app, which NvDA can fall victim to if code injection routine somehow calls the tampered function somehow).

Tanks.
Hi,

Also, regarding additional reasons given, they still fall under closing security and privacy hole, so can you tell us more compelling justifications other than this?

To answer the question about why NVDA logs its activity: the info level logs bare minimum such as which modules were loaded, errors, navigator object information (if requested) and what not.

Thanks.
As NVDA isn't able to read from its own logfile, why it creates one at all? If everything works fine, nothing should be logged by NVDA – even not the minimum information with their timestamps in milliseconds. Well, and forensic isn't an argument here because Windows itself logs thousands of things. But this isn't an argument against disabling NVDA's logging too at the same time.

Yep, and regarding malware: As NVDA is open source it will be quite hard to protect the end user against debug logging. In the end the warning prompts will not help, but this is a general issue which effects every software.

Maybe the whole logging functionality could be extracted from NVDA. So, if someone wants to provide any logfiles or crash dump he has to install a debug add-on first. Without this little add-on, both feature are functionless. But this would be a quite lot of work. I would say that this maybe isn't a suitable solution at all, but the first in my mind how to protect normal user completely from logging.
Hi,

Hmmm, I see.

A few questions:

* Suppose a "normal user" is using NVDA with all traces of logging off. Then he or she comes across an issue that only log content can be used to obtain more info. Do you think that's a fair justification to commit to this solution?
* Suppose a user does turn off logging facility out of security and privacy concerns, and somehow finds oneself dealing with an issue that does require developers to get whatever they need. Do you think this is right?
* Do you think many so-called "normal users" would care about data privacy right away despite being told that, under right circumstances, NVDA can log input/output info?
* What is better: willing to make NVDA better by sharing an important log fragment that demonstrates a bug, or just turning off logging altogether out of fear of this leaking out to the world without users knowing it?
* What do you think is better: have content ready to be served upon request, or provide a key that locks or unlocks what's inside without giving good reasons?

I would like to request this a third time: so far, all the reasons and scenarios given have to do with closing security and privacy hole. Can you tell us a compelling justification or two as to why the proposed solution is good? Also, who will this benefit, including how and why?

Thanks.
Hi,

By the way, there is a way to achieve what you're looking for: running NVDA in secure mode (from Run dialog (Windows+R), type "nvda -mrs") without quotes). If this solution is sufficient for you (and others), I'll close this issue.

Thanks.
"-mrs" doesn't stop logging. And "-l" also not. This isn't a solution!

Well, and on the other hand you couldn't tell me why it is so difficult to explain an user how to temporary enable logging via an add-on. Do you really thing it's okay that non-sense information for the end user is logged every time? Why?

Well, one more security reason: If an malware is installed on you PC and it changes the NVDA logging level and sends the NVDA logfile to a C&C server, you entered password on a website as well as all other IO has compromised. And not all websites support 2FA yet.

Okay, one last argument from my side: Advertisement. If you extract all the logging and crash dump functionality from NVDA into an add-on, you can say that NVDA is the most secure screen reader on the globe because absolutely nothing is logged.

At this point I really strongly recommend to calm down and wait to listen what the others say to this issue.
Hi,

One more thing: let me know if I sounded very harsh throughout this exchange.

Thanks.
[**@DrSooom**](https://github.com/DrSooom) commented on [19 Jul 2018, 04:21 CEST](https://github.com/nvaccess/nvda/issues/8516#issuecomment-406133557 "2018-07-19T02:21:56Z - Replied by Github Reply Comments"):
> If the bluetooth name of a braille display contains personal data like the name of the owner and this information is logged by NVDA data, then of course it effects the GDPR. Because maybe someone wants to connect his braille display to a –let's say – public PC or to an non-trustable PC, the owner of those PCs could find out the real name of the owner of the braille display, even if he didn't want that.

If one connects his bluetooth device to a pc, logging is also performed at the Windows level and the bluetooth device is most likely saved as paired device at that particular system itself. NVDA's logging doesn't contribute to a privacy issue here, in my opinion. Note that one who doesn't want his name to be publicly available should just not put it in bluetooth names.

I think we should only consider investigating this issue if there is some statement in the GDPR that explicitly states that this kind of logging of personal data is not allowed. Note that the log is *never* updated to NV Access or the NVDA project unless you explicitly do this yourself. On many public places, the temp folder is automatically erased when you log off. Furthermore, there are many applications that log relevant data we don't even know about. I'm pretty sure that screen reading software like ZoomText and JAWS perform logging at a similar level as NVDA does.
Hi,

Can creating an add-on resolve this: yes... and no. Yes, provided that this add-on is willing to patch various NVDA functions, including C++ code. Unfortunately, because of current routines, it cannot be done.

As for this being an advertisement pitch: telling people that NVDA is secure because logging facility is completely turned off, yet also advertising an add-on that can "restore logging features and debug NVDA", is, to me, a form of deceptive advertising. Deceptive advertising not only damages the ethos of the advertiser, but also the credibility of NVDA, NV Access, and the global NVDA community. Thus, although this may have good intentions, I think it might not be a good idea to use this solution as part of an advertisement literature.

Thanks.
@josephsl: Our discussion remembers me on discussion about using Threema and Signal instead of WhatsApp, Facebook Messenger and SMS. Metadata without the message content itself also provides sensible data. Just try to find out how many metadata are stored when submitting a tweet on Twitter. (btw: My tweets are protected since my registration, but Twitter knows all. That's what you have to know.)

Okay, but it's good to know that extracting the logging functionality isn't possible at the moment (July 2018).

And to the ad point: How many NVDA users are posting issues in compare with all NVDA users? Sadly, no one can really say this. If – let's say – 95 % of all NVDA users never provides logfiles and crash dumps, I see no reason why NVDA have to log something for them. It makes no sense. And if the run into an issue, we should give them a step by step manual in different languages how to enable logging and how to act with logfiles in combination with privacy.

Remember that I set up a clean Thunderbird Portable copy for bug #8396 because I don't wanted that anyone can see my private Thunderbird instance. But how many NVDA users will do this? I don't think that anyone here is able to say this because we all have different backgrounds and experiences. so in my opinion that's why we haven't the permission to put a bunch of unknown users into a specific group.

btw: Apple also support additional diagnostics on iOS which has manually to be activate via an link on an e-mail from Apple for a specific ticket. (I checked this out right now because I don't want to say anything wrong.)

@leonardder: As JAWS and ZoomText aren't open source you aren't able to know this exactly. And we should not forget that those two products have to be activated as well which will additional data to their companies. Okay, in the meantime it's just one – VFO.
I have to say, I've noticed many other some commercial pieces of software 
creating logs with often personal info in them under certain conditions 
including Dropbox and Adobe, so is this really a greater problem than with 
these other pieces of software?
 If its security, maybe we need to find out what the min standard is 
supposed to be, its very easy to become so paranoid as to make a system 
unusable.

Brian 


The GDPR intends to protect the personal data of EU residents and the data which is deemed personal is:
1. Basic identity information such as name, email, address, and ID numbers
2. Web data such as location, IP address, cookies data, and RFID tags
3. Health, genetic, and biometric data
4. Racial or ethnic data
5. Political opinions
6. Sexual orientation

In this discussion, the only potential bit of "personally identifiable information" considered is Bluetooth device name. By itself, a Bluetooth device name is not an indicator of something personal. I can choose to name my display Dragon's display or Wizard's stafff. No one but I know what such a name means. 

The regulatory regime recognizes collection, processing and control as three separate mechanisms. As collection of this data remains on the machine controlled by an individual while explicitly not collecting data fitting into the six categories defined above, GDPR would not apply.

As to some malware redefining logging level and capturing user data--it can easily do so whether or not the level is set at info, the current default, or the proposed "no logging." Completely disabling logging as a potential deterrent weighed against the significant benefit that logging provides as a support mechanism argues for keeping the logging system as it is.
[**@josephsl**](https://github.com/josephsl) commented on [Jul 18, 2018, 9:55 PM MDT](https://github.com/nvaccess/nvda/issues/8516#issuecomment-406146817 "2018-07-19T03:55:13Z - Replied by Github Reply Comments"):
> Hi,
> 
> One more thing: let me know if I sounded very harsh throughout this exchange.
> 
> Thanks.


A bit, yes.
[**@josephsl**](https://github.com/josephsl) commented on [Jul 18, 2018, 7:33 PM MDT](https://github.com/nvaccess/nvda/issues/8516#issuecomment-406126082 "2018-07-19T01:33:45Z - Replied by Github Reply Comments"):
> Hi,
> 
> 2018 GDPR...
> 
> Can you tell us one or two compelling justifications other than closing security and privacy hole as to why this should be done?

What compelling additional justiication is needed? Security/privacy is very important, and being blind is no exception to security/privacy. This request seems very reasonable for us to look into. I also don't think this would be hard at all. We have a logHandler.NullLogHandler for -s, we could simply add a config option.

The thing here is it shouldn't be hard for us to add a config option for no logging, and just initialize the null log handler, which throws away all logging requests immediately (It doesn't even write them to disk). Beyond that, it doesn't seem reasonable to do other things.
I agree with @derekriemer.
> We have a logHandler.NullLogHandler for -s, we could simply add a config option.

That would be new to me because it isn't descripted in NVDA's User Guide (EN and DE in NVDA alpha-15720,a5e45550, July 31, 2018).

Quote from the userGuide.html (chapter: 15.1. Command Line Options):
> -s | --secure | Secure mode (disable Python console)

Maybe it might be helpful for somebody, who isn't familiar with Python, to know what exactly the Python console can be used for and what limitations are there when disabling it.

Resolving patch:
diff --git a/source/gui/settingsDialogs.py b/source/gui/settingsDialogs.py
--- a/source/gui/settingsDialogs.py
+++ b/source/gui/settingsDialogs.py
@@ -596,6 +596,8 @@ class GeneralSettingsPanel(SettingsPanel):
 	# Translators: This is the label for the general settings panel.
 	title = _("General")
 	LOG_LEVELS = (
+		# Translators: One of the log levels of NVDA (the disabled mode turns off logging completely).
+		(log.OFF, _("disabled")),
 		# Translators: One of the log levels of NVDA (the info mode shows info as NVDA runs).
 		(log.INFO, _("info")),
 		# Translators: One of the log levels of NVDA (the debug warning shows debugging messages and warnings as NVDA runs).
diff --git a/source/logHandler.py b/source/logHandler.py
--- a/source/logHandler.py
+++ b/source/logHandler.py
@@ -1,6 +1,6 @@
 #logHandler.py
 #A part of NonVisual Desktop Access (NVDA)
-#Copyright (C) 2007-2016 NV Access Limited, Rui Batista
+#Copyright (C) 2007-2018 NV Access Limited, Rui Batista, Joseph Lee
 #This file is covered by the GNU General Public License.
 #See the file COPYING for more details.
 
@@ -12,6 +12,7 @@
 import warnings
 from encodings import utf_8
 import logging
+# #7105: Python 3 split the following into two dictionaries.
 from logging import _levelNames as levelNames
 import inspect
 import winsound
@@ -114,6 +115,7 @@ class Logger(logging.Logger):
 	# Our custom levels.
 	IO = 12
 	DEBUGWARNING = 15
+	OFF = 100
 
 	def _log(self, level, msg, args, exc_info=None, extra=None, codepath=None, activateLogViewer=False, stack_info=None):
 		if not extra:
@@ -313,16 +315,18 @@ def initialize(shouldDoRemoteLogging=False):
 	global log
 	logging.addLevelName(Logger.DEBUGWARNING, "DEBUGWARNING")
 	logging.addLevelName(Logger.IO, "IO")
+	logging.addLevelName(Logger.OFF, "OFF")
 	if not shouldDoRemoteLogging:
 		# This produces log entries such as the following:
 		# IO - inputCore.InputManager.executeGesture (09:17:40.724):
 		# Input: kb(desktop):v
 		logFormatter=Formatter("%(levelname)s - %(codepath)s (%(asctime)s.%(msecs)03d):\n%(message)s", "%H:%M:%S")
-		if globalVars.appArgs.secure:
+		if (globalVars.appArgs.secure or globalVars.appArgs.noLogging) and (not globalVars.appArgs.debugLogging and globalVars.appArgs.logLevel == 0):
 			# Don't log in secure mode.
+			# #8516: also if logging is completely turned off.
 			logHandler = logging.NullHandler()
 			# There's no point in logging anything at all, since it'll go nowhere.
-			log.setLevel(100)
+			log.setLevel(Logger.OFF)
 		else:
 			if not globalVars.appArgs.logFileName:
 				globalVars.appArgs.logFileName = _getDefaultLogFilePath()
@@ -350,14 +354,16 @@ def initialize(shouldDoRemoteLogging=False):
 def setLogLevelFromConfig():
 	"""Set the log level based on the current configuration.
 	"""
-	if globalVars.appArgs.debugLogging or globalVars.appArgs.logLevel != 0 or globalVars.appArgs.secure:
+	if globalVars.appArgs.debugLogging or globalVars.appArgs.logLevel != 0 or globalVars.appArgs.secure or globalVars.appArgs.noLogging:
 		# Log level was overridden on the command line or we're running in secure mode,
 		# so don't set it.
 		return
 	import config
 	levelName=config.conf["general"]["loggingLevel"]
 	level = levelNames.get(levelName)
-	if not level or level > log.INFO:
+	# The lone exception to level higher than INFO is "OFF" (100).
+	# Setting a log level to something other than options found in the GUI is unsupported.
+	if level not in (log.DEBUG, log.IO, log.DEBUGWARNING, log.INFO, log.OFF):
 		log.warning("invalid setting for logging level: %s" % levelName)
 		level = log.INFO
 		config.conf["general"]["loggingLevel"] = levelNames[log.INFO]


Test patch: