Redaction in Debug Output

[nmccann]

Hi, I - like many I'm sure - have found the debug output capabilities of the TCA to be immensely helpful in both understanding how the architecture works, as well as in troubleshooting bugs. However, it comes with the downside of potentially leaking sensitive information. While it is only enabled in debug builds (and only if you use debug() or one of it's equivalents on your reducer), this could still be problematic.

I originally thought this would need a change within the TCA itself, but then realized I could introduce my own redaction via a custom type conforming to CustomDebugOutputConvertible, such as:

struct Redacted<T>: CustomDebugOutputConvertible {
var secret: T

var debugOutput: String {
"**redacted**"
}
}

I'm not entirely convinced that such a type should be embedded within the TCA to help with this edge case, but perhaps the documentation should mention the risk of leaking sensitive information and point users towards CustomDebugOutputConvertible? Originally I was using CustomStringConvertible and CustomDebugStringConvertible without luck, before finding that CustomDebugOutputConvertible was needed (the switch statement in Debug.swift looks like it only falls back to CustomStringConvertible/CustomDebugStringConvertible for primitive properties that have no children of their own.

Alternatively, perhaps the DebugEnvironment could have a function that determines if a given label (and it's values) should be included/excluded from debug output, which would allow one to specify a blacklist.

Edit: Perhaps an even better approach for a generic Redacted type would be:

struct Redacted<T>: CustomReflectable {
  var secret: T

  init(secret: T) {
    self.secret = secret
  }

  public var customMirror: Mirror {
    Mirror(self, unlabeledChildren: ["**redacted**"], displayStyle: .optional)
  }
}

Though if you had some runtime capabilities that depended on reflection, this might be undesirable.

[lukeredpath]

Something like this could be generally useful, definitely. I actually implemented something similar to this in our app - we have a reducer that reports certain actions to New Relic using their breadcrumbs feature and I needed to ensure we redacted sensitive action parameters e.g. passwords or any PII.

The high level reducer function just takes an ActionFilter type, which is just a witness style wrapper around an (Action) -> Action? closure. This lets you return nil to exclude an action entirely or you can return a new action with redacted parameters.

[nmccann]

I'd be interested to learn more about your ActionFilter type, would you be able to share a gist demonstrating it's usage?

I agree that redaction functionality would be generally useful, I'm just not sure that the TCA should have an opinion on it, as I could see it varying drastically from one project to another. In my particular case, I like that my Redacted<> type makes it obvious which parameters contain sensitive information, but it adds overhead when using those parameters elsewhere. I don't mind because it doesn't happen often. But I could see others finding that problematic, or they might want it redacted in TCA related logs but not in other logs.

Hence why I think just documenting the concern, or providing a customization point in the DebugEnvironment would be a good compromise.

[lukeredpath]

It's just a simple struct that wraps a closure, e.g.:

struct ActionFiltering<Action> {
  var filter: (Action) -> Action?
}

The high level reducer accepts one of these to filter out actions. An implementation might be for example:

let filter: ActionFiltering<AppAction> = .init { action in
  case let .login(email, password):
    return .login(email, "[REDACTED]")
  case .someActionWeWantToSkip:
    return nil
  default:
    return action
}