Android Key Store/Nimbus experiment control telemetry probes

[grigoryk]

tbd

┆Issue is synchronized with this Jira Task

[grigoryk]

I think landing a simple "experiment" component in A-C makes sense; it'll emit facts about what happens during init/write/read. We can "invoke" that component in Fenix whenever we'd read the keys normally (for now, that can be alongside other storage init, in the visual completeness queue), and process emitted facts into glean metrics.

Once the experiment is over, we will remove the isolated component and any associated code in Fenix.

[Mugurell]

I was looking into this trying to understand the requirements and I see them as following:

• a Nimbus experiment to easily control whether specific telemetry would be recorded or not
  who can set this up?
• because downloading the Nimbus experiments may take some time we need to preemptively cache all the events we're interested in in a FIFO structure to not loose anything that may have happened before knowing if we should track that or not (default is should not)
  I'm thinking that the facts should get to Fenix which will be the one responsable for caching and sending them or disposing them based on the experiment.
  This would mean modifying the code to emit the Facts and after we'll not be needing it the commit can be reverted.
• what exact methods should we track?
  The Android Keystore is used for SecureAbove22Preferences which has the init/r/w methods.
  There is also the KeyStoreWrapper.
• Fact will be emitted for the various events.
  Are we interested in only method calls or is there any other data that should be tracked?
• these Facts will get to Fenix which will cache & log / dispose them based on the experiment.
  The new telemetry will be of type event with lifetime application.
  The expiration date will be the same as for the experiment.

@grigoryk Can you confirm the above? / Offer more info about the specifics needed?

[grigoryk]

Discussed this w/ @Mugurell on Slack, but basically:

• in Secure prefs (read: AndroidKeyStore) reliability experiment android-components#9819 a "reliability experiment" is added
• it should be invoked whenever we'd normally try to access an encryption key. An explicit place would be whenever we initialize our storage layers on the visual completeness queue, in queueInitStorageAndServices.
• in both of these cases, we will end up running our experiment at some point soon after startup, but not quite at startup
• we only want to invoke this experiment class if we're enrolled in a nimbus experiment. If it's time to run it within the queue, but we're not sure yet about nimbus state, simply don't run it and wait until the next startup.
• reliability experiment will emit facts, so those need to be mapped to (new, to addd) metrics in MetricsController

[Mugurell]

The patch has been merged and uplifted.
However it is currently disabled pending a Nimbus experiment.

[grigoryk]

@Mugurell also, see #18502 :)

[jdragojevic]

If I'm not mistaken @Mugurell - this is done, right?

[amedyne]

@grigoryk will be setting up the experiment in Nimbus to Launch the experiment.

[grigoryk]

This was done.