1807023 - Record successfully matched and failed-to-match extension ids during import

Status: RESOLVED FIXED

(Firefox :: Migration, task, P3)

Description

[Ania]

If a user initiates the import from a Chromium-based browser to Firefox, we would like to record their Chromium installed extension ids, in order to be able to recommend or install the same extensions if they are present in the Firefox add-ons store.

This would help to reduce the gap Firefox currently has with Chromium browsers that can import extensions seamlessly.

Is the only ethically appropriate way to do it would be to ask a user to share their add-on information or offer them to import add-ons directly?

Comment 1

[Ania]

Hi Chris,
I hoped to ask for your expertise on this as we are trying to make a decision whether we should invest in extensions import.
Collecting information about the installed Chromium extensions would help us understand how we should approach extensions import, e.g.:

• how many extensions users have on average,
• how many of the installed extensions are represented in Chromium Top-100 extensions that we can realistically match.

Comment 2

[Chris H-C :chutten]

If by "record" you mean "put on disk and use locally", then this isn't considered Data Collection. Browsers store a lot more things that are spicier than extension ids, and leave them on disk. By all means go ahead.

If by "record" you mean something like "collect and send via Glean", then I believe the data would be Category 3 Stored Communications and thus would need to undergo sensitive data review if you wanted it to be collected default-on. With appropriate risk mitigations in place I think we'd be able to show that collecting and reporting these ids wouldn't put our users at risk and so would be permitted (though as a Data Steward I only help kick off the process. I don't make the decision).

Comment 3

[Ania]

Thank you so much, Chris! We were looking into more of the "collect and send via Glean", so we'll go for the sensitive data review path IF we decide that we want to record this data before implementing the add-ons import.

Comment 4

[Chris H-C :chutten]

Turns out I was wrong about the whole Category 3 thing. Recently we've had some clarification over here in Data Stewardship land that so-called-"identifiers" that aren't tied to humans somehow (by e.g. email address) are actually Cat1. This applies to the ids of the addons that are installed or available or migrated or whatever.

That would mean that lists of addon ids are, being Category 1 Technical data, eligible for default-on collection in any or all release channels.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Thanks, chutten!

According to #data-help, a Glean string list is the right way to record this: https://mozilla.github.io/glean/book/reference/metrics/string_list.html

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1807023 - Record successfully matched and failed-to-match extension ids during import. data-review=chutten. r?willdurand!

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Hey willdurand,

Is this an okay place to put this probe? Also, please let me know if you can think of a cleaner way of doing this kind of thing - I did what I thought was simplest, but definitely open to suggestions.

Comment 8

[William Durand [:willdurand]]

I think that's fine if you don't need to record this probe only when a user wants to import extensions (e.g. something else calls getMappedAddons()).

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Hm, good point. Would you be okay with it if I modified getMappedAddons to return an object of this structure:

{ importedAddons: array<AddonSearchResult>, matchedIDs: array<string>, unmatchedIDs: array<string> }

?

Comment 10

[William Durand [:willdurand]]

Yeah, that should be fine.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Attachment: Data collection request

This was my first time using ./mach data-review. Neat!

Comment 12

[Chris H-C :chutten]

Comment on attachment 9346540 [details]
Data collection request

PRELIMINARY NOTES:
Glad you liked ./mach data-review!

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.

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

Yes. This collection 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?

Yes, Mike Conley is responsible.

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

Category 1, Technical.

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

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

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

Yes.

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

No.

---

Result: datareview+

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5479f753fcc9
Record successfully matched and failed-to-match extension ids during import. data-review=chutten. r=willdurand

Comment 14

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/5479f753fcc9

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9345660 [details]
Bug 1807023 - Record successfully matched and failed-to-match extension ids during import. data-review=chutten. r?willdurand!

Beta/Release Uplift Approval Request

• User impact if declined: None, but we won't get decent telemetry on which Chrome extensions users are trying to (and failing to) find appropriate mappings for when importing to Firefox.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is telemetry only, and has been baking on Nightly for a few days now. The changes to add the probes are small and well understood as low-risk.
• String changes made/needed: None.
• Is Android affected?: No

Comment 16

[Dianna Smith [:diannaS]]

Comment on attachment 9345660 [details]
Bug 1807023 - Record successfully matched and failed-to-match extension ids during import. data-review=chutten. r?willdurand!

Approved for 117.0b6

Comment 17

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/bdc6a7a881ad