telemetry ids should be obscured in log

[Hoverbear]

(Draft atop #55)

We don't want users to accidentally reveal their user data to us if they're asking for help, so we redact it in logs.

[linear]

DS-267 telemetry IDs should be obscured in log output

If we ask users to copy paste logs with trace log levels, we'll get their distinct ID. Since that ID is personal, we'd rather not make it identifying. How about we obscure it for logging?

[cole-h]

I wonder if it would be worth it to manually implement whatever this (%) is using (Display? Debug? maybe even both?) and redact the distinct ID there (which would necessitate a type / newtype wrapper for it, probably).

Otherwise, if we ever print out this header_data somewhere else, we'll have to remember this function exists and to use it.

[Hoverbear]

% is shorthand for Display. ? is shorthand for debug.

I played with wrapping the type a bit yeah. tokio-rs/valuable#75 would make this quite easy. 😅

[cole-h]

I've opened https://linear.app/detsys/issue/DS-273/fsm-encode-the-obscured-telemetry-distinct-id-in-the-structs-type so that we can tackle this separately.

[grahamc]

Looks like this needs a rebase. I'm also interested in some sort of separation of "this is an explicit request for unredacted data" and "gonna print this out".

One option could be that Telemetry has the data portion split out where Telemetry has a TelemetryData, which has a ->redacted() and ->unredacted() as accessors. What do you think about this?

If you consider this "gold plating" I'd be amenable to that.

[cole-h]

I'd also be willing to tackle that as part of another PR, so we can get this merged sooner rather than later.

Ana had an idea of making the distinct_id an Option and then sending the request using something like with_distinct_id(), so that it's usually not present.

[Hoverbear]

I'll rebase this now and we can merge it