privacy considerations

[SergeyKanzhelev]

Issues cleaning continued: adding some privacy notes for #55. I'll tag it that issue with correlation-context tag once this PR is complete. So it will not be in the main query

[wu-sheng]

Platforms and tracing systems MUST NOT include any personal identifieable information into tracestate header.

I think OpenTracing should be noticed, the baggage concepts will have some conflicts with the Privacy rules, if some supported tracers support both this spec and OT.

FYI @tedsuo

[SergeyKanzhelev]

Platforms and tracing systems MUST NOT include any personal identifieable information into tracestate header.

I think OpenTracing should be noticed, the baggage concepts will have some conflicts with the Privacy rules, if some supported tracers support both this spec and OT.

I added privacy note to make sure any service may store and propagate tracestate without much privacy concerns. So the idea is ONLY store non-identifiable information there like application ID, sampling and such. For baggage Correlation-Context header should be used.

[bogdandrutu]

Not necessary a privacy concern, more like an usability concern is when the service initiating calls use the same trace-parent every time then this cause the service owner to not be able to distinguish between different calls. this my be solved by restarting the trace on the service side if the client is untrusted.

[SergeyKanzhelev]

Yes. I'd start security section for this. This doc purpose was to ensure the traceparent and tracestate can be stored and transmitted without implications for privacy and things like GDPR.

[CodingFabian]

👍 from my side. It would be a good idea to explicitly mention that there must be no storage restrictions on the tracestate value.

[SergeyKanzhelev]

@CodingFabian I made it more explicit

[tedsuo]

@wu-sheng I think baggage is a separate issue, related to correlation-context, not tracestate.

LGTM, except fot the bit about mutating the tracestate.

If the suggestion is that systems MUST NOT include any personal identifieable information into tracestate header, then the follow up suggestion that systems extremely sensitive for personal information exposure MAY implement selective removal of values corresponded to the unknown keys doesn't really make sense.

"Extremely sensitive systems" should be following the main privacy directive, and not be putting "unkown keys" into their tracestate to begin with. (I presume the suggestion here is not to mess with other systems tracestate, but with previous instances of your tracestate).

Simply saying "don't put any personally identifiable information in tracestate" should be enough for now, the nuance muddles the message IMHO.

[SergeyKanzhelev]

@tedsuo I realize there are some re-iteration of the same. I intentionally mentioned it as there are services who will want to have an extra level of protection and will want to blacklist. Not talking theoretically =)

The language can be cleaned up though and I'd propose we clean it with upcoming editors clean up.

Thank you for feedback. If you still believe the language needs to change factually - please file an issue. Haven't meant to disregard your feedback here