Hi Zellyn, this sounds like a reasonable idea. As the next step could you perhaps write up a short proposal with more details on what exactly it would mean for a field to be redacted? To me it seems like the important thing would be to make sure it's clear how redacted fields are supposed to be behave in each situation (i.e. when they should be dropped or not), so that there's no uncertainty about when they're dropped and when they're preserved. (For example, we might say that they're never shown when a proto is implicitly stringified but maybe preserved in all other situations?) We might also need to be careful to get this right for all languages early; even if there's some language where we don't care about redaction for now, it will be hard to change later without making a breaking change.
On Thu, Feb 16, 2017 at 1:45 PM, zellyn via Protocol Buffers < [email protected]> wrote: > There are many ways that protocol buffers might be stringified into logs, > accidentally or on purpose, printed in stack traces, etc. The built-in > behavior stringifies the entire protobuf recursively, including all field > data. > > At Square, we deal with payments, and often have data of varying > sensitivity in protobuf fields, which we'd like to be elided from > stringified output. > > We use an internal fork of protoc to handle a custom field option, > "redacted", and have also patched the stringification code to print > "[REDACTED]" for those fields. We do the same in Go, and in the C > implementation (for Ruby). > > Last year, we chatted with the protobuf team, and they were sympathetic to > our use case (in fact, they mentioned that the part of Google that deals > with payments has something similar internally: I think that's where the > "sensitive" name came from). I'd like to get that discussion rolling again. > > We'd like to see one of the following happen (in decreasing order of > awesomeness for us): > > - upstreaming of the "redacted" field option, and modification of the > runtimes to elide redacted fields when stringifying > - introduction of generic interception points to selectively override > default stringification behavior in Java, Go, and Ruby (at least). > - addition of a "SerializeToString" or equivalent method, and removal > of default full-stringification behavior of the toString (Java), String > (Go), etc. - that way you only serialize on purpose > - many tests rely on string comparison, even though nobody is > supposed to rely on it being stable - perhaps the default behavior could > compute a hash? > > Josh Humpries (who now works at Fullstory) created a proposal > <https://github.com/google/protobuf/issues/1160> a while back, but it > didn't go anywhere. I reached out to the protobuf team, and Damien Neil > suggested that this group was the appropriate place to propose such changes. > > Bikeshed away! > > Zellyn > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
