1873080 - data_storage.entries metric should be collected with `set`, not `add`

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

The data_storage.entries metric is collected using add, which means we get useless results, since we're essentially collecting some unknown multiple of the number of data storage entries. We should be using set.

Comment 1

[Donal Meehan [:dmeehan]]

:keeler do you want to track this as an S1?
Setting S1 as the severity automatically requests tracking.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: Bug 1873080 - change data_storage.entries metric to quantity metrics r?jschanck

Before this patch, data_storage.entries was a labeled counter (where the label
identified the nsIDataStorage being measured). Counters only support adding to
the value being tracked, so in practice what was measured was approximately
some unknown multiple of the number of entries in each nsIDataStorage.

This patch splits data_storage.entries into data_storage.alternate_services,
data_storage.client_auth_remember_list, and
data_storage.site_security_service_state, each of which are quantities. This
way, we can measure exactly how many entries are in each nsIDataStorage.

Depends on D197709

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I guess since this doesn't affect users directly, it's not an S1.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: request.md

Comment 5

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Comment on attachment 9371190 [details]
request.md

data-review+

---

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes.

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, [e-mail] will monitor.

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, interaction data.

5. Is the data collection request for default-on or default-off?

Default-on.

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No.

7. Is the data collection covered by the existing Firefox privacy notice?

Yes.

8. Does the data collection use a third-party collection tool?

No.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/567f5a81c441
change data_storage.entries metric to quantity metrics r=jschanck

Comment 7

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/567f5a81c441