1600399 - Document intended contacts with data review programs

Status: RESOLVED WORKSFORME

(Data Platform and Tools :: Glean: SDK, task, P3)

Description

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Consider the case of adding telemetry to a component library that we can use from multiple products, like https://github.com/mozilla/application-services vs Lockwise and Firefox Preview.

I'm confused by these requirements:

• The Glean book says that data-review is necessary to add Glean collections to a library. This implies that it's the library's responsibility to perform data-review and publish metrics documentation.
• :Dexter asserts that those libraries should then publish in their READMEs that an additional data-review is required to embed the library. This implies that it's the embedding application's responsibility to perform data-review and publish metrics documentation.

This would be coherent, but only if the embedded library and the embedded application have different policies. Are all Glean clients subject to the Firefox Privacy Notice? Do they all make identical promises to the user? (Do we contemplate third-party use?) If "yes and yes," the application-level review feels redundant. Is the goal to consider both the principle and the integration? I'm not sure the data stewardship program is really equipped to assess implementations.

Ultimately, it's the embedding application that has a privacy policy and makes promises to a user. The data-review process asks questions about the populations to observe and the available opt-out mechanisms—is it appropriate to answer for a library in isolation? Are we just trying to get a certification that collections are level 1 or 2? If an application-level review has value, when we change or expand a collection in a reusable component, shouldn't we have to repeat data-review for the embedding applications? Who's responsible for understanding which products are affected by a change to a library? What are the mechanisms for doing that?

I think it would be helpful to achieve and document some consensus.

Comment 1

[Ryan Kelly [:rfkelly]]

There is a bit of related conversation in Bug 1598247 (but from an application-development perspective, not a data-review perspective).

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Tim Smith 👨‍🔬 [:tdsmith] from comment #0)

Consider the case of adding telemetry to a component library that we can use from multiple products, like https://github.com/mozilla/application-services vs Lockwise and Firefox Preview.

For reference, there's a bunch of other components that do the same: for example engine-gecko-nightly, firefox-accounts, storage-sync.

I'm confused by these requirements:

• The Glean book says that data-review is necessary to add Glean collections to a library. This implies that it's the library's responsibility to perform data-review and publish metrics documentation.

In Android Components, components are meant to be reusable pieces of code that can be plugged into multiple products. This is true for both implemented features and telemetry data: metrics defined at component level should be designed to be re-usable and relevant to other products embedding the component.

Think of 'engine-gecko', for example: that's a component wrapping GeckoView, which takes care of exfiltrating performance data from Gecko to Glean pings. These metrics are not meant specifically for Fenix but, rather, are meant for measuring Gecko/GeckoView.

Metrics that are specifically meant for Fenix should be declared, implemented and documented in Fenix (and other products).

Components owner are responsible for asking for data-review and own the metric their component define.

• :Dexter asserts that those libraries should then publish in their READMEs that an additional data-review is required to embed the library. This implies that it's the embedding application's responsibility to perform data-review and publish metrics documentation.

This is to make it "no surprise". Components should clearly advertise that they collect telemetry and that the telemetry will be sent using Glean, if the product also supports Glean.

We really want product owners/engineers to be intentional about their collection.

This would be coherent, but only if the embedded library and the embedded application have different policies. Are all Glean clients subject to the Firefox Privacy Notice? Do they all make identical promises to the user? (Do we contemplate third-party use?) If "yes and yes," the application-level review feels redundant. Is the goal to consider both the principle and the integration? I'm not sure the data stewardship program is really equipped to assess implementations.

This is a good point. We're working (well, Chris is) to create an expedite data-review process for integrating Glean-enabled components in Glean-enabled products.

Ultimately, it's the embedding application that has a privacy policy and makes promises to a user. The data-review process asks questions about the populations to observe and the available opt-out mechanisms—is it appropriate to answer for a library in isolation?

Populations probably only make sense at application level.
Opt-out mechanism is a requirement for using the Glean SDK itself so, even if redundant, it makes more sense to have an application level question for this.

Both the above don't make much sense at component level, I agree.

Are we just trying to get a certification that collections are level 1 or 2?

What do you mean?

If an application-level review has value, when we change or expand a collection in a reusable component, shouldn't we have to repeat data-review for the embedding applications?
Who's responsible for understanding which products are affected by a change to a library? What are the mechanisms for doing that?

I have opinions on these, but I'm not sure I'm the best person to address them :) Would it help to have a meeting about this to discuss it a bit more?

Comment 3

[Alessio Placitelli [:Dexter]]

(In reply to Alessio Placitelli [:Dexter] from comment #2)

This would be coherent, but only if the embedded library and the embedded application have different policies. Are all Glean clients subject to the Firefox Privacy Notice? Do they all make identical promises to the user? (Do we contemplate third-party use?) If "yes and yes," the application-level review feels redundant. Is the goal to consider both the principle and the integration? I'm not sure the data stewardship program is really equipped to assess implementations.

This is a good point. We're working (well, Chris is) to create an expedite data-review process for integrating Glean-enabled components in Glean-enabled products.

Errata: Chris is working on expedite forms to add Glean into products, not Glean-enabled components in Glean-enabled products.

Comment 4

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

Are we just trying to get a certification that collections are level 1 or 2?

What do you mean?

Category 1 or 2, per https://wiki.mozilla.org/Firefox/Data_Collection — we can often (but not always) be confident that a collection in a library isn't going to be able to report web activity data or PII, no matter how the embedder holds it. It seems probably reasonable to assess that at the component level.

Would it help to have a meeting about this to discuss it a bit more?

I was kind of hoping that someone else from stewardship would grab hold of this, but my tactical inaction hasn't succeeded yet. :) I'll see who I can scare up.

Comment 5

[Alessio Placitelli [:Dexter]]

(In reply to Tim Smith 👨‍🔬 [:tdsmith] from comment #4)

Would it help to have a meeting about this to discuss it a bit more?

I was kind of hoping that someone else from stewardship would grab hold of this, but my tactical inaction hasn't succeeded yet. :) I'll see who I can scare up.

No need to scare people :)

Chris, is there anything you can do to help with this? You know both about Glean and Data Stewardship, maybe you could help shedding some light on where things are getting fuzzy here?

Comment 6

[Chris H-C :chutten]

"tactical inaction" might also describe how I've been lurking on this bug : )

(Here begins the section where I write what Alessio said, but using slightly different words)

The way data collection in Android Components works is that each component wants to collect metrics and have whatever the embedding application is take care of the UI to enable/disable, and actually embed the code to schedule and send the data. This bifurcates the Data Collection Review as, at the point in time a library is adding new collections, they only know the current populations the library is exposed to.

But we need to check that the collections are adhering to the Privacy Notice, and that requires Data Stewards and forms and discussions with the people who own the data at the point in time that they're adding it. So we review the individual collections there, and agree that "opt-out mechanisms are provided by the embedding application" is an acceptable answer to Data Collection Review Request Question 8, and acknowledge that Question 7's answer is current as of writing. (And Q11 is unanswerable at all)

When the library gets added to a new application, that application supplies the missing parts of Q7 and Q8 as well as the whole answer for Q11. It's a good time for the Application to affirm that there are new data collections involved. And from now on, Data Collection Reviews for the library should include this new Application in its list of known populations.

All this is a side-effect of how Android Components takes what are, in Firefox Desktop, informal module boundaries and formalizes them. As such I figure we Data Stewards need acknowledge the informal boundaries in the Data Collection Review forms. This does mean one extra review for each application that embeds a data-collecting library, but the reviews within the libraries are almost-but-not-quite-exactly like the ones we know from Firefox Desktop and friends.

Does that make sense, tdsmith?

Comment 7

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

(In reply to Chris H-C :chutten from comment #6)

As such I figure we Data Stewards need acknowledge the informal boundaries in the Data Collection Review forms.

"Formal," I guess, right?

Does that make sense, tdsmith?

Works for me if it works for Trust. :)

Comment 8

[Alessio Placitelli [:Dexter]]

Given comment 6 and comment 7, I'm closing this bug. Please feel free to re-open if needed.