On Sunday, June 30, 2013 07:02:04 PM Matthew Toseland wrote: > Freemail has a file describing what should be logged at what level, attached > below. > > I have tried to define something similar for Freenet: It's been suggested > more than once that we should only log potentially privacy-breaking data at > MINOR etc. > > The problem is, it's not obvious that we can say "only log anything > incriminating at DEBUG", for example. > > What is incriminating? There are two separate issues: > > 1. Keys being fetched by the user, etc. > 2. IP addresses etc. > > When posting logs anonymously, the latter may be more dangerous than the > former. When posting logs publicly it's the other way around. > > There may be legitimate reasons to log potentially incriminating data > concerning both of these: - Something has gone severely wrong with a > download. We need to identify the download. Normally we'd want to handle > this through the user interface, e.g. show it as failed... - Something has > gone severely wrong with a peer (a darknet peer, in which case we want the > name, or an opennet peer, in which case we may want the IP address). You > may want to tell your peer about it, e.g. get them to fix their software, > you may want to disconnect from them, block them at the IP level etc etc. > > So how can we have a coherent policy? > > My initial thoughts were: > - ERROR: Something the user needs to do something about, or that severely > breaks the node i.e. we need to "excuse" or explain it; the user should fix > the problem or report the error. Normally if it's fixable we'll post a > useralert, so mostly this is "report the error". - WARNING: Something that > could be a problem if it happens often. > - MINOR: Detailed debugging, logging individual events in detail. > - DEBUG: Crazily detailed debugging, e.g. logging encryption keys etc for > some low-level debugging. Not usually used.
I think you're choosing the wrong measurement here. The loglevel should not be a measurement of privacy, because that is not fixable anyway. Logs will always contain private data. Especially the nature of errors is that they are out of your control and thus also cannot be controlled to not contain private data. Instead, you want to measure the severity of the issue, and for non-severe stuff such as MINOR, how much of debug code it is. With WOT, I am doing it this way: - ERROR is only used when something is *definitely* broken. That makes test runs very easy: I search the log files for ERROR, and the test run is only successful if there are none. Notice how this is an opposite to fred where ERROR spamming is normal :P :) - WARNING is used for conditions which are unwanted but can occur due to things which we cannot control. Being a P2P network, the perfect example is that we received data which is out of the bounds of what is allowed - that can always happen when remote people are allowed to send stuff to you. For example the nickname of a WOT identity might contain disallowed characters. Having a separate log level for this is nice because monitoring significant WARNING logging is critical to detecting excessive amounts of invalid data, which might indicate DoS or a bug in the code which checks validity. - NORMAL is major events. They occur with low frequency so the computation of the log strings is not heavy even if NORMAL logging is disabled. Typically these events are produced by the UI. An example is creating an identity in the WOT web interface. A Freenet example would be a finished download. - MINOR is data for debugging purposes. It occurs with high frequency and therefor has an "if(logMINOR)" guard to prevent computation of the log strings if the MINOR logging is disabled. It can be heavy amounts of logging but enabling MINOR logging should NOT change the behavior of the surrounding program. - DEBUG logging is the same as MINOR with the primary difference that DEBUG can enable additional code paths which would not normally be executed. Those code paths typically solely exist to compute data for the logging. For WOT for example this means that it will run an additional integrity test upon the database during startup. I've committed an amended version of this description of WOT log levels to: https://github.com/freenet/plugin-WoT-staging/commit/594f71e9563852cd8c5b6cc49b85a0f0b27a2938 Thanks for inspiring me to do this :)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
