Add the ability to completely disable NVDA's logging (including NVDA's crash dumps) #8516
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? 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 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? |
|
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:
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 commented on 19 Jul 2018, 04:21 CEST:
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:
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 commented on Jul 18, 2018, 9:55 PM MDT:
A bit, yes. |
|
@josephsl commented on Jul 18, 2018, 7:33 PM MDT:
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. |
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):
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. |
|
Hi, uh oh, we need to document the fact that it also turns off logging. As for overall arguments, I admit defeat (I lost). Thanks.
|
|
One more thing in the userGuide.html (chapter: 15.2. System Wide Parameters):
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. |
|
Hi, yep, an oversight. Thanks.
|
|
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. |
|
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. |
|
@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. |
|
Hi, the little known __debug__ flag is useful for detecting whether or not one is using a debug build. As for crash dumps, I’d say it should be done via Python Console when instructed to do so, so no need for a checkbox. Thanks.
|
|
@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? |
|
Hi, right now, if you wish to create a crash dump across NVDA release channels, you need to open Python Console from the app you know is prone to crashes, and call a function that captures crash dumps when NVDA actually crashes. The underlying assumption is that crash dumps are needed when users can verify that crashes occur often and with specific steps. Is this what you are after? Thanks.
|
|
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. |
|
I think disabling logging totally is still for improving security. Crash dumps are not created automatically when NVDA starts which is ok in my opinion.
Von meinem iPhone gesendet
… Am 01.08.2018 um 06:35 schrieb Joseph Lee ***@***.***>:
Hi, right now, if you wish to create a crash dump across NVDA release channels, you need to open Python Console from the app you know is prone to crashes, and call a function that captures crash dumps when NVDA actually crashes. The underlying assumption is that crash dumps are needed when users can verify that crashes occur often and with specific steps. Is this what you are after? Thanks.
From: Daniel Mayr ***@***.***>
Sent: Tuesday, July 31, 2018 9:32 PM
To: nvaccess/nvda ***@***.***>
Cc: Joseph Lee ***@***.***>; Mention ***@***.***>
Subject: Re: [nvaccess/nvda] Add the ability to completely disable NVDA's logging (including NVDA's crash dumps) (#8516)
@josephsl <https://github.com/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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#8516 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkHuWQtUEMkEhlwGPvqytsYlGq_sEks5uMS9AgaJpZM4VVjVZ> .
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Hi, not all users may notice this file being created, as this is not created every time (something we need to look at another time). As for Python Console method, I’m glad we’re on the same page. Also, for whoever is working on this, don’t use log level of 0 (not set), as it’ll handle all sorts of log messages – I think it might be best to use log level of 100 (disabled). Thanks.
|
|
Quote from this Wiki article:
|
|
Hi, a mini dump won’t contain all memory contents used by NVDA – it’ll contain current register values, stack traces and what not – barely minimal info useful for debugging only. To me, this is not really a security and privacy concern… unless a special command-line switch could be introduced to prevent crash dumps from being created, which will be in effet for the current session only. Thanks.
|
|
@DrSooom commented on Jul 31, 2018, 10:31 PM MDT:
We also have versionInfo.isTestVersion. |
|
@DrSooom commented on Jul 31, 2018, 10:47 PM MDT:
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. |
|
See the logHandler.py. There's a line "if globalVars.appArgs.secure" line, and you can add the no logging config stuff there. |
|
Hi, I’ll cook up something, along with researching ways to modernize the ancient log handler module (this is important, as Python 3 may introduce backwards incompatible changes to log handler). Thanks.
|
|
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. |
|
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. |
…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).
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).
… 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.
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.
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.
Paths:
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
The text was updated successfully, but these errors were encountered: