Closed Bug 2054438 Opened 1 month ago Closed 7 days ago

Enable new Glean App `firefox-enterprise.desktop`

Categories

(Data Platform and Tools :: General, task, P1)

Product:
Data Platform and Tools
Component:
General
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: michael, Assigned: janerik)

References

(Blocks 1 open bug)

Details

(Whiteboard: [dataplatform])

See: https://github.com/mozilla/probe-scraper/pull/1035

Application ID: firefox-enterprise.desktop
Application Canonical Name: Firefox Enterprise
Description: Managed, open-source browsing at scale
Data-review response link: same as base Firefox
Repository URL: https://github.com/mozilla/enterprise-firefox (branch enterprise-main)
Locations of metrics.yaml files (can be many):
- browser/actors/metrics.yaml
- browser/components/aiwindow/metrics.yaml
- browser/components/asrouter/metrics.yaml
- browser/components/attribution/metrics.yaml
- browser/components/backup/metrics.yaml
- browser/components/contentsharing/metrics.yaml
- browser/components/contextualidentity/metrics.yaml
- browser/components/controlcenter/metrics.yaml
- browser/components/customkeys/metrics.yaml
- browser/components/downloads/metrics.yaml
- browser/components/extensions/metrics.yaml
- browser/components/firefoxview/metrics.yaml
- browser/components/genai/metrics.yaml
- browser/components/ipprotection/metrics.yaml
- browser/components/metrics.yaml
- browser/components/migration/metrics.yaml
- browser/components/newtab/metrics.yaml
- browser/components/places/metrics.yaml
- browser/components/preferences/metrics.yaml
- browser/components/privatebrowsing/metrics.yaml
- browser/components/profiles/metrics.yaml
- browser/components/protections/metrics.yaml
- browser/components/protocolhandler/metrics.yaml
- browser/components/screenshots/metrics.yaml
- browser/components/search/metrics.yaml
- browser/components/sessionstore/metrics.yaml
- browser/components/sidebar/metrics.yaml
- browser/components/tabbrowser/metrics.yaml
- browser/components/tabnotes/metrics.yaml
- browser/components/taskbartabs/metrics.yaml
- browser/components/textrecognition/metrics.yaml
- browser/components/urlbar/metrics.yaml
- browser/extensions/search-detection/metrics.yaml
- browser/modules/metrics.yaml
- dom/media/platforms/wmf/metrics.yaml
- services/fxaccounts/metrics.yaml
- toolkit/components/contentanalysis/metrics.yaml
- toolkit/components/contentrelevancy/metrics.yaml
- toolkit/components/crashes/metrics.yaml
- toolkit/components/nimbus/metrics.yaml
- toolkit/components/pictureinpicture/metrics.yaml
- toolkit/components/places/metrics.yaml
- toolkit/components/reportbrokensite/metrics.yaml
- toolkit/components/satchel/megalist/metrics.yaml
- toolkit/components/search/metrics.yaml
- toolkit/components/telemetry/metrics.yaml
- toolkit/modules/metrics.yaml
- toolkit/mozapps/update/shared_metrics.yaml
- widget/cocoa/metrics.yaml
- widget/gtk/metrics.yaml
- widget/windows/metrics.yaml

Locations of pings.yaml files (can be many):
- browser/components/asrouter/pings.yaml
- browser/components/backup/pings.yaml
- browser/components/enterprisepolicies/pings.yaml
- browser/components/newtab/pings.yaml
- browser/components/profiles/pings.yaml
- browser/components/search/pings.yaml
- browser/components/urlbar/pings.yaml
- browser/modules/pings.yaml
- services/fxaccounts/pings.yaml
- services/sync/pings.yaml
- toolkit/components/nimbus/pings.yaml
- toolkit/components/reportbrokensite/pings.yaml
- toolkit/components/telemetry/pings.yaml
- toolkit/modules/pings.yaml
- toolkit/mozapps/update/shared_pings.yaml
- toolkit/profile/pings.yaml

Dependencies:
- gecko
- glean-core
- crashping

Retention Days: 400

Data access restrictions: Yes

Would it be possible to hide the App from the list in https://dictionary.telemetry.mozilla.org/ but still make the documentation for the pings and metrics accessible?

Duplicate of this bug: 2049586
Whiteboard: [dataplatform]

Sorry for the delay here. I'm going to pick this up now.

Assignee: nobody → jrediger
Status: NEW → ASSIGNED
Priority: -- → P1

Application ID: firefox-enterprise.desktop

✅

Data access restrictions: Yes

Who needs access?

Would it be possible to hide the App from the list in https://dictionary.telemetry.mozilla.org/ but still make the documentation for the pings and metrics accessible?

No. At the moment we don't hide active apps that do send us data.

Data-review response link: same as base Firefox

:chutten, is this enough? (do we have that link?) -- Or is this a new audience and thus should require a proper full data review first?

Locations of metrics.yaml files

Firefox Desktop currently lists all their files in https://searchfox.org/firefox-main/source/toolkit/components/glean/metrics_index.py, which is parsed daily to update repositories.yaml.
How does Enterprise want to handle that? Do we need to extend the updater to extend the Enterprise entry as well?

Flags: needinfo?(michael)
Flags: needinfo?(chutten)

Who needs access?

How does Enterprise want to handle that? Do we need to extend the updater to extend the Enterprise entry as well?

Enterprise is just a fork and it also uses the metrics_index.py to track both new pings and metric files so we probably should extend the updater.

Flags: needinfo?(michael)

(In reply to Jan-Erik Rediger [:janerik] from comment #3)

Data-review response link: same as base Firefox

:chutten, is this enough? (do we have that link?) -- Or is this a new audience and thus should require a proper full data review first?

The closest I have to-hand is bug 1591564, the first use of the Glean SDK in m-c. This process wasn't as established back then, so finding a direct analogue may be impossible.

IIRC the intent behind this requirement is to make sure that the baseline collections inherent to the Glean SDK are permissible under the new product's Privacy Notice (e.g. Klar has different privacy expectations than mainline Firefox for Android). :michael, is data collection for Firefox Enterprise covered under the Firefox Privacy Notice? If not (and I imagine it might not be since the "user" of FxEn might be the corp, not the person using the browser), then we should file a data review request and response showing that everything's above board. It'll require Sensitive Data Collection review because of the use of baseline identifiers (client_id most notably, but you're inheriting all Cat3+ from base Firefox at the same time, so it's more than just "is the Glean SDK's collection okay"), but I imagine it'll be a straightforward one.

If it is subject to the same text and interpretation as Firefox, then I think it's within Data Stewardship's remit to data-r+ it here as "Firefox, but Enterprise-flavoured".

(( That it's okay to collect this data from this audience is not really in doubt here. The important thing is to show our work for those who come looking. ))

Flags: needinfo?(chutten) → needinfo?(michael)

is data collection for Firefox Enterprise covered under the Firefox Privacy Notice?

That depends, from a Enterprise Browser User perspective we are not covered under the Firefox Privacy Notice because we transmit additional metrics that are not part of the standard Firefox Metrics (for example a custom event when a file is downloaded with the full name and URL of the file in the event). However, this data is transmitted to the controlling corporation, not Mozilla. The corp can then decide what subset of the telemetry data that is covered under the Firefox Privacy Notice is transmitted back to the standard Mozilla Glean Pipeline (we would explicitly exclude any of the Enterprise specific metrics to be re-transmitted to us).

So from a user perspective the privacy expectation towards Mozilla is always as high or higher then standard Firefox. The privacy expectation towards the Corporation is different, but that is out of our control.

Flags: needinfo?(michael)

Members of Trust and Legal and Data Stewardship and the Data Collection Tools Team are going to have a meeting hopefully this week to discuss and decide this.

We've had the meeting and, as of our understanding of the current structure of the Firefox Enterprise browser, we are indeed collecting this Firefox-Desktop-style telemetry under the Firefox Privacy Notice and so we can indeed approve it the same as Firefox Desktop's approved. That means its data must be documented, though, and I know that was a subject of discussion on the PR.

So this is Data Stewardship's data-review+ on adding the application to the pipeline.

That means we can go ahead and add ffx enterprise to probe-scraper.

I filed bug 2063212 for the necessary fog-updater changes.
:michael, is this something you could do? Should be rather straight-forward, duplicating the existing logic from Desktop for Enterprise.

We did also notice that in some places you use #ifdef MOZ_ENTERPRISE in metrics.yaml definition files for enterprise-only metrics.
Those are purely visually. These files are parsed by glean_parser, which has no idea about any preprocessor directives. These lines are interpreted as comments.
While this works right now, because those files only have the lines in the enterprise repository, it seems a bit fragile.
It seems splitting out those extra metric into separate files might be more appropriate (e.g. a metrics_enterprise.yaml right next to the other one).

Flags: needinfo?(michael)
See Also: → 2063254

Yeah, I can update the fog-updater. Will push a patch tomorrow.

Flags: needinfo?(michael)

(In reply to Michael van Straten [:michael] from comment #4)

Who needs access?

How does Enterprise want to handle that? Do we need to extend the updater to extend the Enterprise entry as well?

Enterprise is just a fork and it also uses the metrics_index.py to track both new pings and metric files so we probably should extend the updater.

:whd I'm in the process of moving this ahead. As per the process this will require a PR to restrict access. what needs to be done to create a work group for this subset of people?

Flags: needinfo?(whd)

:whd I'm in the process of moving this ahead. As per the process this will require a PR to restrict access. what needs to be done to create a work group for this subset of people?

workgroup:fx-enterprise is probably the correct workgroup to use. The data-viewers subgroup is per https://mozilla-hub.atlassian.net/wiki/spaces/SRE/pages/2492956683/Workgroups#Well-known-Subgroups expected to be used for cases like this. The process basically requires updating https://github.com/mozilla/global-platform-admin/blob/main/google-workspace-management/tf/workgroups/fx-enterprise.yaml to add the new subgroup, with written approval from the sponsor somewhere like this ticket. See the aforementioned doc and also these skills which can help with preparing and reviewing the PR.

Once the subgroup is defined the metadata in https://github.com/mozilla-services/cloudops-infra/blob/master/projects/data-shared/tf/prod/envs/prod/bigquery-new/namespaces.auto.tfvars.json can be used to restrict access to the data. Per https://mozilla-hub.atlassian.net/browse/SVCSE-3457 DPE now mostly owns these processes and can help file the appropriate PRs.

Flags: needinfo?(whd)

Rob, can someone from your team help setting up that group?

Michael, looks like we need written approval from your sponsor: the Director above you. Can you forward this and make sure that happens?

Flags: needinfo?(rmiller)
Flags: needinfo?(michael)

Can do, if you send me a link to the ticket.

Flags: needinfo?(michael)

(In reply to Michael van Straten [:michael] from comment #4)

Who needs access?

It's this ticket :) -- It's enough if they quote the above and state that that's the group that should get data access.

Flags: needinfo?(michael)

[:hcondei], could you look over this list and approve it if it makes sense to you.

Flags: needinfo?(michael) → needinfo?(hcondei)

This is approved.

Flags: needinfo?(rmiller)
Flags: needinfo?(hcondei)

(In reply to Arkadiusz Komarzewski [:akomar] from comment #18)

Subgroup creation: https://github.com/mozilla/global-platform-admin/pull/7156
Access restriction: https://github.com/mozilla-services/cloudops-infra/pull/6983

Both PRs are merged. That means this is all done now!

Status: ASSIGNED → RESOLVED
Closed: 7 days ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.