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. What Freemail says: ## Error ## Warning Logging at this level is enabled by default. ## Normal ## Minor General timing info. This should be at minor so slow operations can be debugged without asking the user to enable debug level logging. ## Debug Anything that contains keys (except publicly known ones) Message slots All other security sensitive information -- Toad, official Freenet codemonkey, back to working full time on Freenet after a study break. (This FMS identity is not secure, it is run on my behalf by a friend. Look for a signature. I will sign anything important, either signing the message, or signing the files I am referring to; the signatures *ARE* secure.)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
