Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to completely disable NVDA's logging (including NVDA's crash dumps) #8516

Closed
DrSooom opened this Issue Jul 19, 2018 · 40 comments

Comments

Projects
None yet
8 participants
@DrSooom
Copy link

DrSooom commented Jul 19, 2018

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

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

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.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

Hi,

I should have said, "one or two additional justifications other than closing security and privacy hole". Thanks.

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Jul 19, 2018

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 and this wiki article.

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?

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

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.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

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.

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Jul 19, 2018

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.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

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.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

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.

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Jul 19, 2018

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

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

Hi,

One more thing: let me know if I sounded very harsh throughout this exchange.

Thanks.

@leonardder

This comment has been minimized.

Copy link
Collaborator

leonardder commented Jul 19, 2018

@DrSooom commented on 19 Jul 2018, 04:21 CEST:

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.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 19, 2018

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.

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Jul 19, 2018

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

@Brian1Gaff

This comment has been minimized.

Copy link

Brian1Gaff commented Jul 19, 2018

@PratikP1

This comment has been minimized.

Copy link

PratikP1 commented Jul 19, 2018

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.

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Jul 30, 2018

@josephsl commented on Jul 18, 2018, 9:55 PM MDT:

Hi,

One more thing: let me know if I sounded very harsh throughout this exchange.

Thanks.

A bit, yes.

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Jul 30, 2018

@josephsl commented on Jul 18, 2018, 7:33 PM MDT:

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.

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Jul 30, 2018

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.

@Adriani90

This comment has been minimized.

Copy link
Collaborator

Adriani90 commented Jul 30, 2018

I agree with @derekriemer.

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Jul 31, 2018

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.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 31, 2018

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Jul 31, 2018

One more thing in the userGuide.html (chapter: 15.2. System Wide Parameters):

serviceDebug | … | … | If enabled, disables secure mode on windows secure desktops, allowing the use of the Python console and Log viewer. Due to several major security implications, the use of this option is strongly discouraged

This description should be expand as well. At the moment it only says something about the Log Viewer, but not also about the logging itself. A clarification here would be appreciated.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Jul 31, 2018

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Jul 31, 2018

Please see #8579. I intend to get this documentation oversight fixed. I'm really sorry we confused you. An disable logging however would be nice to have. I'll keep this open in case anyone wants to make it an option.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 1, 2018

Hi,

For anyone wishing to work on this, I recommend setting log level to 0 (if that is even an option) and adding "off" option to logging level combo box. Also, at least log the fact that logging is turned off at startup.

Good luck. Thanks.

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Aug 1, 2018

@derekriemer: Thank you very much for opening this new issue.

One more question: What's about disabling creating the dump crash files during a crash of NVDA? It also could contain sensible data. Is it possible to combine this with the new logging level ("no logging" or "off") or would be a checkbox in the General NVDA Settings better?

If we create a new checkbox for the NVDA dump files only, I suggest to set this value to false by default. You should also not forget that unreproducible bugs are quite hard to fix. so in my opinion the end user should only enable it if a developer really needs this crash dump.

And another question: Is it possible to set the logging level and the creating crash dump value to different values by default depending on the kind of NVDA version? so it would be possible to set the logging level on alpha build directly to debug – and enable creating crash dumps here as well. But both settings are different by default on RC and stable versions. I know that this will make it a little bit more complex, but I guess it will help testers and devs quite a lot – and protect the end user by default at the same time.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 1, 2018

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Aug 1, 2018

@josephsl: In other words: Creating crash dumps should be disabled by default in all kinds of NVDA versions – which isn't the case yet. Correct?

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 1, 2018

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Aug 1, 2018

As far as I recognized NVDA 2018.1 (installed version) creates a file called "nvda_crash.dmp" by default. This behaviour can't be disabled via the GUI.

As far as I understood you, your suggestion is to disable this behaviour, so the user firstly have to enable it via the Python console if he need one. This procedure would be fine to me.

@Adriani90

This comment has been minimized.

Copy link
Collaborator

Adriani90 commented Aug 1, 2018

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 1, 2018

@DrSooom

This comment has been minimized.

Copy link
Author

DrSooom commented Aug 1, 2018

Quote from this Wiki article:

Crash Dumps
This applies to NVDA 2014.1 and later. Earlier versions do not generate crash dumps.
If NVDA crashes, it will generate a file called a minidump which will help developers to determine the cause of the crash. In addition, minidumps can also be generated on request for other applications which crash if NVDA is suspected as the cause of the crash.
Minidumps for NVDA Itself
When NVDA crashes, it will usually restart itself. In some rare circumstances, this may not work. If NVDA crashes, a minidump will be generated in a file called nvda_crash.dmp. For most users, this file can be found in the user temporary folder %temp%. For users running from source, nvda_crash.dmp will be placed in the source directory.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 1, 2018

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Aug 2, 2018

@DrSooom commented on Jul 31, 2018, 10:31 PM MDT:

@josephsl: In other words: Creating crash dumps should be disabled by default in all kinds of NVDA versions – which isn't the case yet. Correct?

We also have versionInfo.isTestVersion.

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Aug 2, 2018

@DrSooom commented on Jul 31, 2018, 10:47 PM MDT:

As far as I recognized NVDA 2018.1 (installed version) creates a file called "nvda_crash.dmp" by default. This behaviour can't be disabled via the GUI.

As far as I understood you, your suggestion is to disable this behaviour, so the user firstly have to enable it via the Python console if he need one. This procedure would be fine to me.

Actually, that's only correct if NVDA crashes other applications. We create dumps for ourself by default. They're minidumps, so the amount of info is more minial. if you want NVDA to request other applications dump on crash, you have to ask NVDA to do this in that application.

@derekriemer

This comment has been minimized.

Copy link
Collaborator

derekriemer commented Aug 2, 2018

See the logHandler.py. There's a line "if globalVars.appArgs.secure" line, and you can add the no logging config stuff there.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 2, 2018

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 2, 2018

Hi,

Turns out logging cannot be turned off all the way: when binary version of NVDA (installed or portable) starts, NVDA will log a sign-on message, along with where your settings can be found. This is because our logger will write log contents to the log file as soon as the log file is ready for writing.

One way to get around this is to have an in-memory "log" (buffer) ready to hold startup messages, and then dump it to the "actual" log file if log level other than "disabled" is chosen.

One major concern I have: should logging be enabled/disabled on the fly? That is, if logging level changes to "disabled", should previous log content be kept, and if changing from "disabled" to something else, should future log contents be prepared for writing? I'm thinking this change should require a restart to fully take effect. The major downside with this approach is loss of bug traces, especially if the bug does not happen when NVDA restarts.

Thanks.

@josephsl

This comment has been minimized.

Copy link
Collaborator

josephsl commented Aug 2, 2018

Hi,

Regarding modernizing log handler, I put in some note regarding log level name dictionary splits. For whoever's going to port this file to Python 3, be sure to read Python 3 documentation on logging module carefully, as so-called "_levelNames" map is gone in Python 3.

Thanks.

josephsl added a commit to josephsl/nvda that referenced this issue Aug 2, 2018

Add a new command-line switch (--no-logging) that'll completely turn …
…off logging functionality. re nvaccess#8516.

If NVDA is run with --no-logging, logging facility will be turned off altogether. This is handy for not only testing this feature, but also for those who'd like to add this command-line switch while defining nVDA shortcut on the desktop or add this from Run dialog (Windows+R).

josephsl added a commit to josephsl/nvda that referenced this issue Aug 2, 2018

Log handler: add support for no logging switch. Re nvaccess#8516.
Switch to null logger if no logging flag is turned on via command-line switches. Also, detect log level of 'OFF' and set log level accordingly (to 100).

josephsl added a commit to josephsl/nvda that referenced this issue Aug 2, 2018

josephsl added a commit to josephsl/nvda that referenced this issue Aug 2, 2018

User guide: document log levels and improved command-line description…
… for secure mode. Re nvaccess#8516.

Describe available logging modes and what they mean. Also, when edscribing secure mode, add the fact that logging is turned off. Lastly, add an entry in command-line switches table for --no-logging switch.

josephsl added a commit to josephsl/nvda that referenced this issue Dec 14, 2018

No logging: address review actions. Re nvaccess#8516.
Changes made:
* log level checks: now a tuple will be checked.
* Allow users to override no logging and logging during secure mode via debug logging or predefined logging levels via command line switches. This means no log will be written if secure mode is active and/or no loggin is specified, and if no debug logging nor custom log levels are given.

@nvaccessAuto nvaccessAuto added this to the 2018.4 milestone Dec 17, 2018

feerrenrut added a commit that referenced this issue Dec 17, 2018

Logging: add an option to turn logging off altogether (PR #8596)
Closes #8516

- Log level 100 can be used to switch to null logger if no logging flag is turned on via command-line switches. 
- Add a new command-line switch (--no-logging) that'll completely turn off logging functionality.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.