Collect category 1-2 data and enable background price updates from consenting users in privacy-sensitive contexts #186
Comments
chuckharmston
added
the
[ENG]: Triage
muccimoz
removed
the
[ENG]: Triage
Osmose
changed the title
|
There's a |
It's associated with my scattered brain. Amended and apologies! |
|
We will also need to update the "Opt Out" section of METRICS.md accordingly. |
|
@chuckharmston Did we get approval for these changes as part of the Data Collection Review? Edit: Doesn't look like it just yet. |
|
We did! Conversation starts here: https://bugzilla.mozilla.org/show_bug.cgi?id=1501420#c7 |
|
Ah, the second paragraph of that comment is what you are referring to, since we are only enabling Cat 1-2 data for DNT, TP and Cookie settings and still disabling any telemetry of any category in Private Browsing. Okay thanks. |
|
@chuckharmston , Re: Row 1, Column 1 of your table: disabling Price Polling in Private Browsing is a little complicated (our conversation starts here, and is handled by a separate issue (#177 )). For that reason, we currently do not disable Price Polling in Private Browsing. Would you accept a patch that addressed everything here except that one case, which would be handled by #177 ? Please note that #177 is not currently in our list of issues to fix during this post-launch Milestone. |
…ontexts In order to avoid the eslint `no-cycle` error, I moved all events to be registered to their own `events.js` script, so that both `privacy.js` and `extension.js` could import from `events.js`. (thanks Osmose for the idea) More about the `no-cycle` error that was avoided: This error came up when I tried to import CATEGORY_3_EVENTS from `./src/telemetry/extension.js` into `./src/privacy.js`, since we were already importing `shouldCollectTelemetry` from the latter into the former.
Previously, price polling (a.k.a. background price updates) was disabled when Do Not Track, Tracking Protection or certain cookie settings ('reject_third_party' and 'reject_all') were enabled.
Now, price polling occurs in these situations. This leaves the `shouldUpdatePrices` function in `privacy.js` kind of useless, but I left it there instead of removing it entirely in order to add the Private Browsing check that is part of mozilla#177.
|
That's definitely fine, although it'd be great to try to bring #177 into that milestone. I've inquired about that on the bug. |
…ontexts In order to avoid the eslint `no-cycle` error, I moved all events to be registered to their own `events.js` script, so that both `privacy.js` and `extension.js` could import from `events.js`. (thanks Osmose for the idea) More about the `no-cycle` error that was avoided: This error came up when I tried to import CATEGORY_3_EVENTS from `./src/telemetry/extension.js` into `./src/privacy.js`, since we were already importing `shouldCollectTelemetry` from the latter into the former.
Fix #186: Enable event telemetry and price polling in certain privacy contexts
Moving out a comment from #72:
As @johngruen mentioned in Slack yesterday evening, the traditional Test Pilot practice to not send any usage information for users with DNT or Tracking Protection largely exists because Test Pilot experiments generally use Google Analytics to collect data. Since we're using event telemetry, that gives us a bit of leeway.
That said, we still do have a responsibility to be as lean as possible when collecting personal data of users regardless of their privacy settings. To that end, I chatted with @groovecoder this morning to try to work out the right place where we get the usage information we need to evaluate and iterate upon the experiment while still respecting users' privacy and wishes. Here's where I landed:
I do think we should omit any category 3 data (i.e. the aggregate counts of visits to sites we support) if DNT, Tracking Protection or cookie settings indicate a user's intent not to be tracked. I do think we should still collect basic extension interaction metrics in those cases. This is consistent with Firefox, which still collects cat 1 + 2 telemetry data from those users.
I propose amending the above table thusly:
falsetrue*true*true*falsetruetruetruefalsetruetruetruefalsefalsefalsefalse* As additional consent to the polling, we should add information to the "no products" screen for these users to make sure that they understand that by adding an item to their list, we'll be checking prices on their behalf. This is tracked in #184.
This all meets @groovecoder's goal of making sure we don't make third-party requests for users with DNT/TP without their consent, and does some great proactive reinforcement of our organizational privacy stance.
This is not MVP, but we should endeavor to land this before launching.
The text was updated successfully, but these errors were encountered: