Add telemetry for the storage access API
Categories
(Core :: Privacy: Anti-Tracking, defect, P2)
Tracking
()
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
Details
(Whiteboard: [anti-tracking])
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
|
Details | Review |
3.81 KB,
text/plain
|
chutten
:
review+
|
Details |
No description provided.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
Comment 3•5 years ago
|
||
Comment on attachment 9039646 [details] Data Review Request DATA COLLECTION REVIEW RESPONSE: Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate? Yes. This collection is Telemetry so is documented in its definitions file ([Histograms.json](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Histograms.json)) and the [Probe Dictionary](https://telemetry.mozilla.org/probe-dictionary/). Is there a control mechanism that allows the user to turn the data collection on and off? Yes. This collection is Telemetry so can be controlled through Firefox's Preferences. If the request is for permanent data collection, is there someone who will monitor the data over time? N/A, this collection expires in Firefox 73. 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. Is the data collection request for default-on or default-off? Default on for pre-release channels only. Does the instrumentation include the addition of any new identifiers? No. Is the data collection covered by the existing Firefox privacy notice? Yes. Does there need to be a check-in in the future to determine whether to renew the data? Yes. :ehsan is responsible for renewing/removing this collection before it expires in Firefox 73. --- Result: datareview+
Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8aab348da9e7 Add telemetry for the storage access API; r=johannh,janerik
Comment 5•5 years ago
|
||
bugherder |
Assignee | ||
Comment 6•5 years ago
|
||
Comment on attachment 9039627 [details]
Bug 1513309 - Add telemetry for the storage access API;
Beta/Release Uplift Approval Request
Feature/Bug causing the regression
Not a regression
User impact if declined
As mentioned in the data review request, one of the use cases for this telemetry is to assess whether the storage access API is being widely used as a mitigation of our default cookie policy restrictions. Denying this approval request will limit our ability to assess whether the privacy of our users through the default cookie restrictions feature will be compromised. We are aiming to enable this feature for 100% of the release channel population in 66.
Is this code covered by automated tests?
No
Has the fix been verified in Nightly?
No
Needs manual test from QE?
No
If yes, steps to reproduce
(It's manually verified in about:telemetry)
List of other uplifts needed
None
Risk to taking this patch
Low
Why is the change risky/not risky? (and alternatives if risky)
It's not really risky, very simple patch to add a histogram when our permission dialog code gets activated.
String changes made/needed
None
Updated•5 years ago
|
Comment 7•5 years ago
|
||
Comment on attachment 9039627 [details]
Bug 1513309 - Add telemetry for the storage access API;
Telemetry support for local storage API use launching in 66; let's uplift for beta 6.
Comment 8•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Updated•5 years ago
|
Description
•