Apologies for the long delay, but I got radically reassigned at work, so I 
haven't had much time to work on this. But it keeps niggling at me, because 
I hate our internal protobuf forks so much.

Here is the proposal: Proto Proposal: a “sensitive” field option 
<https://docs.google.com/document/d/18WI8zN7rk6R0jXW1iC8LDYz7LJ0OrUOTKMGD7nyEnFs>
.

Zellyn

On Wednesday, February 22, 2017 at 12:10:14 PM UTC-5, Adam Cozzette wrote:
>
> 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 <
> prot...@googlegroups.com <javascript:>> 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 protobuf+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to prot...@googlegroups.com 
>> <javascript:>.
>> 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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to