1607267 - Stop using Telemetry to generate filter contexts

Status: NEW

(Firefox :: Normandy Client, enhancement)

Description

[Michael Cooper [:mythmon]]

When evaluating filters for recipes, Normandy builds a context with a bunch of useful data. Some of this data is retrieved directly from the Telemetry environment. This has a couple problems:

1. Telemetry in this form is not available everywhere we want to use Normandy (like on mobile).
2. Telemetry is not designed to be used this way.

Instead we should fetch this data more directly, and not go through Telemetry. We may want to make some common helpers that can be shared between Telemetry and Normandy, but it may also make sense to just re-implement the Telemetry behavior.

If we don't do this, many of the context items that filter objects rely on either return undefined, throw errors or simply hang forever. That last one especially we want to avoid.

Comment 1

[Chris H-C :chutten]

As an additional point, the Glean SDK is designed in such a way to prohibit being used in this way. By the end of 2020 we hope to have all new data collections in Firefox be Glean SDK collections, not Telemetry collections. (We have no plans to stop or change Telemetry at this time. Just redirecting people to start using Glean instead.) This puts a bound on how long Telemetry may remain useful if we choose to continue using it or to modify its design to better support this need.

But that's enough about the problems, let's think about solutions. Presuming that even with Telemetry and Glean SDK failing to support it, there's a product need for a local dataset for client modelling. Spitballing in meetings, :kparlante and I have thought about how much overlap their is between Telemetry/Glean SDK data collection libraries and whatever we'd have to build to satisfy Normandy's use case.

There are some bits of the Glean SDK that a system serving this need could benefit from: definitions files, expiry dates, high-level data types, generated global APIs, ... and all of that lives in the glean_parser build-time scripts. Organizationally-speaking, the needs differ. Instead of packing data for pings and network and so forth, we'd want to persist in a way that aids analysis. The persistence format would probably want to be datasets rather than pings.

How cool would it be to have an incredibly-rich model in Firefox that never leaves the profile. Messaging, experiments, feature recommendations, activity stream... all could send recipes that check against this central model without us ever being able to target or identify individuals. If I didn't have my hands full this year with the aforementioned Glean SDK implementation (aka Project FOG) I'd be quite interested in starting up the requirements-gathering and design proposals to support this.

Comment 2

[Michael Cooper [:mythmon]]

To be a bit more concrete and clear about what this bug is about: This isn't about the ability of filter expressions to access arbitrary Telemetry (though that is something we should explore as well). This is about code like this (edited for clarity):

static get os() {
  return (async() => {
    const { system } = TelemetryEnvironment.currentEnvironment;
    const rv = { isWindows: AppConstants.platform === "win" };

    if (rv.isWindows) {
      rv.windowsVersion = coerceToNumber(system.os.version);
      rv.windowsBuildNumber = system.os.windowsBuildNumber;
    }
  })();
}

Here Normandy is providing an os key to filter objects. In calculating the value of that field, it uses Telemetry to generate the value since it was complicated to figure out, and Telemetry had that field just lying there. This is the thing we should stop.