Consider using a hash of clientId to key Unified Telemetry data (instead of using clientId directly).

RESOLVED WONTFIX

Status

Cloud Services
Metrics: Pipeline
P2
normal
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: mreid, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [unifiedTelemetry])

(Reporter)

Description

3 years ago
In the interests of placing an upper bound on the length of the primary key used for longitudinal analysis, it may be better to use a hash of the raw clientId instead of the clientId itself. 

I filed this bug because I noticed a few crash submissions with the following:
"clientId":"593836                                                                             8c-ddc6-4cfa-91b2-24614767c823"

With all kinds of extra spaces.

Is the tradeoff in complexity and indirection worthwhile?
(Reporter)

Comment 1

3 years ago
As discussed in today's triage, it would be better to validate that the client is sending well-formed UUIDs for the "clientId" field and then non-UUID values to the error stream on the server.
(Reporter)

Updated

3 years ago
Priority: -- → P2
Whiteboard: [unifiedTelemetry]

Comment 2

3 years ago
Based on the discussion, should we close this as invalid?
Flags: needinfo?(mark.bugzilla)
(Reporter)

Comment 3

3 years ago
Yep.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

3 years ago
Flags: needinfo?(mark.bugzilla)
You need to log in before you can comment on or make changes to this bug.