Bugzilla

(In reply to Dave Townsend [:mossop] from comment #1)
> The current `clientId` is implemented in `ClientID.sys.mjs`, canonically stored in `datareporting/state.json` in the profile and cached for synchronous access in the `toolkit.telemetry.cachedClientID` preference. Storing the new group ID similarly makes sense. It probably makes sense to also manage this in the `ClientID.sys.mjs` module rather than creating a new module as we can share some aspects of the code. In particular we probably want to make sure we clear the group ID when the client ID is cleared.

I concur that there's a lot of shared behaviour we want to reuse for group_id from client_id, but I don't think clearing it is one of those behaviours. To my knowledge the group id remains in force and unchanged on a profile even when data upload is disabled since prefs (including data upload) are per-profile, not per-group.

(( Of course, if the only use of the group id is for data upload then it doesn't matter whether or not it is present since it'll never enter a new ping. ))

> At one point it was suggested that the group ID have a different form from a client ID so the two are easily distinguishable. This could be as simple as adding a prefix or using a UUID without the dashes.

This has a good intention, but if we wish to transmit this using Glean it would likely make most sense as [a `uuid` metric](https://mozilla.github.io/glean/book/reference/metrics/uuid.html) which normalizes its value to the standard hyphenated uuid (but without surrounding `{}`) format for storage and transmission. Setting an invalid or misshapen uuid value is not supported.

We could use uuid-valid but not-uuidv4-generatable values (at a higher risk of collision) by e.g. 1337-coding a prefix like 612009 (loosely "GROOP") ((this is what we do for the [canary `"c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0"` value](https://mozilla.github.io/glean/dev/core/internal/clearing.html) )), or we could put it in a `string` metric instead.
 
> Presumably there will need to be some server-side changes for this. I'm not sure what, chutten can you give some direction here?

Only when/if there is some behaviour specific to the group id that we want different from all other `uuid` metrics. 

> While this is something that Firefox leadership has signed off on I am assuming we will still need to go through the sensitive data review process here?

Correct. At least as paperwork to show we've gone through our process and haven't cut any corners.

(In reply to Dave Townsend [:mossop] from comment #1)
> The current `clientId` is implemented in `ClientID.sys.mjs`, canonically stored in `datareporting/state.json` in the profile and cached for synchronous access in the `toolkit.telemetry.cachedClientID` preference. Storing the new group ID similarly makes sense. It probably makes sense to also manage this in the `ClientID.sys.mjs` module rather than creating a new module as we can share some aspects of the code. In particular we probably want to make sure we clear the group ID when the client ID is cleared.

I concur that there's a lot of shared behaviour we want to reuse for group_id from client_id, but I don't think clearing it is one of those behaviours. To my knowledge the group id remains in force and unchanged on a profile even when data upload is disabled since prefs (including data upload) are per-profile, not per-group.

(( Of course, if the only use of the group id is for data upload then it doesn't matter whether or not it is present since it'll never enter a new ping. ))

Putting it in `ClientID.sys.mjs` is where I'd want to put it, too.

> At one point it was suggested that the group ID have a different form from a client ID so the two are easily distinguishable. This could be as simple as adding a prefix or using a UUID without the dashes.

This has a good intention, but if we wish to transmit this using Glean it would likely make most sense as [a `uuid` metric](https://mozilla.github.io/glean/book/reference/metrics/uuid.html) which normalizes its value to the standard hyphenated uuid (but without surrounding `{}`) format for storage and transmission. Setting an invalid or misshapen uuid value is not supported.

We could use uuid-valid but not-uuidv4-generatable values (at a higher risk of collision) by e.g. 1337-coding a prefix like 612009 (loosely "GROOP") ((this is what we do for the [canary `"c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0"` value](https://mozilla.github.io/glean/dev/core/internal/clearing.html) )), or we could put it in a `string` metric instead.
 
> Presumably there will need to be some server-side changes for this. I'm not sure what, chutten can you give some direction here?

Only when/if there is some behaviour specific to the group id that we want different from all other `uuid` metrics. 

> While this is something that Firefox leadership has signed off on I am assuming we will still need to go through the sensitive data review process here?

Correct. At least as paperwork to show we've gone through our process and haven't cut any corners.