1  # What is "sensitive" in Arti?
  2  
  3  The [`safelog`] crate gives us a few ways to mark data as "sensitive",
  4  and therefore not to be exposed in the logs by default.  This "safe
  5  logging" is a defense-in-depth mechanism against log disclosure: it is
  6  intended to help if a log file is stolen, or if a user posts part of a
  7  logfile in public without considering its contents.
  8  
  9  Here we discuss several our rules for what must be marked as sensitive,
 10  when.
 11  
 12  ## Which logs does this apply to?
 13  
 14  The `tracing` crate provides the levels "trace", "debug", "info",
 15  "warn", and "error".   We expect that most users will only care about
 16  messages at level "info" or higher, and that "trace" and "debug" are
 17  only useful for development and diagnostic purposes.
 18  
 19  Therefore, most of these rules apply to log messages generated at level
 20  "info" or higher: we expect that "debug" or "trace" logs may be more
 21  dangerous to share.
 22  
 23  > TO DO: Add a warning when logging at severity "debug" or lower? (See #552)
 24  
 25  
 26  
 27  ## Reasons not to log things
 28  
 29  When we treat information as sensitive, we typically do so because it
 30  falls into one of the following categories:
 31  
 32    * **Somebody else's secrets.** This is information that could harm
 33      somebody else's security on the Tor network. Mostly, it applies to
 34      relays.
 35    * **User activity.** This is information about what a particular Tor
 36      user was doing at a given time.
 37    * **User identifiers.** This is information that could potentially
 38      help identify a given user, whether or not it is typically
 39      considered PII.
 40    * **Traffic-analysis helpers.** This is information which could be
 41      useful to an attacker attempting to perform traffic analysis.  (Note
 42      that this category is extremely broad: even the time when Arti was
 43      running can potentially help with traffic analysis. We try to limit
 44      ourselves to issues which help particularly with traffic analysis.)
 45  
 46  
 47  ## Information never to log
 48  
 49  We should **never** log any of these kinds of data, at any level:
 50  
 51    * Private keys of any kind.
 52    * Symmetric encryption keys of any kind.
 53    * Application data being being sent or received over a stream.
 54  
 55  (These are all user activity, or have the potential to expose it.)
 56  
 57  
 58  ## Information that is always sensitive
 59  
 60  This information should be treated as sensitive at level "info" or
 61  higher, and may be treated as sensitive at lower levels:
 62  
 63    * The target address of any application stream. (User activity.)
 64    * The target port of any application stream. (User activity.)
 65    * Any path over the network. (Traffic-analysis helper.)
 66    * A full list of guard nodes. (Traffic-analysis helper.)
 67    * A full bridge address or identity. (Somebody else's secret.)
 68    * Any onion address. (User activity.)
 69    * Any user's IP address or hostname. (User identity.)
 70  
 71  ## Information that _can_ be sensitive.
 72  
 73  This information is often sensitive, and should only be logged at
 74  "info" or higher when necessary to make a diagnostic message usable.
 75  
 76    * Any single relay. (Traffic-analysis helper.)
 77    * The local username. (User identity.)
 78    * Configuration settings that affect network-visible
 79      behavior. (Traffic-analysis helper.)
 80    * Any path on the file system. (User identity.) ❇
 81    * Specific versions of software and dependencies that the user is
 82      running. (User identity, traffic-analysis helper.) ❇
 83  
 84  Items marked above may be also be logged _at startup_, or _at the head
 85  of a rotated log_ file, to assist with diagnosis.
 86  
 87  
 88  
 89  ## Logs to avoid
 90  
 91  We should not trigger a message at "info" or higher based on any of the
 92  following events:
 93  
 94    * An application request being made.
 95    * An application request succeeding.
 96    * An application request failing because of a normal error condition.
 97  
 98  (Rationale: All of these are potentially fine-grained traffic-analysis
 99  helpers.)
100  
101  
102  
103  ## Other ways to mitigate logging
104  
105  > TO DO: We should recommend that people only use logging mechanisms where
106  > old logs are discarded after a not-too-long interval.  (See #550)
107  
108  > TO DO: When possible, we should discourage logging information with
109  > fine-grained time granularity.  (A 1-to-10 second precision is fine for
110  > most use cases!)  (See #551)