DFX Telemetry update

Roadmap
1

A quick update to DFX Telemetry Proposal - #9 by mikhail-turilin on data capture

Here’s a description of the data that will be captured by dfx. This information could help to bring clarity to the privacy implications of enabling dfx telemetry. In short:

  • We don’t collect any personally identifiable information, like canister IDs and IP addresses
  • All long session tracking is happening locally, so that the server can’t do pseudo anonymous behavioral profiling

Common data for all events

  • Platform: #linux, #darwin, #windows
  • dfx version: text
  • Network: #ic; #localProject; #localShared; #other

Command usage stats

We will collect how often each dfx command is executed with some context information:

  • command and subcommand captured as enums
    • dfx canister create is captured as #dfxCanisterCreate enum
  • positional arguments
    • most of the time not captured: in the dfx ledger transfer --icp 1.0 abcd-1233-ffff-eeee --memo 123 --network=ic the destination principal abcd-1233-ffff-eeee is not captured
    • sometimes we capture the number of positional arguments: for example for dfx deploy <canister name>, we will capture the fact of whether dfx is deploying all canisters or only to 1 specific canister (but not the name of that canister)
  • options (like --icp 1.0) are captured as
    • The option’s presence in the command is captured as boolean flag
      • For example: in the dfx ledger transfer --icp 1.0 abcd-1233-ffff-eeee --memo 123 --network=ic the --icp option will be captured as a binary flag
    • The option’s value is captured as an enum that can records the type of option’s value when it’s important
      • For example: dfx canister install, the --mode parameter, we would capture install/reinstall/upgrade/auto.

The only data that is captured as a full value is the dfx version.

Examples of the captured data:

  • dfx start --background
    • #dfxStart enum
    • #optionBackground binary flag
  • dfx ledger transfer --icp 1.0 abcd-1233-ffff-eeee --memo 123 --network=ic
    • #dfxLedgerTransfer
    • #optionIcp
    • #optionMemo
    • #networkIc

Monthly active users

DFX will collect long-running stats (MAU - monthly active users, DAU - daily active users) without exposing any permanent ids to the backend by putting the aggregation logic on the client.

For example, to collect MAU data dfx will:

  • Maintain local cache to determine if the MAU event was already sent in the last 30 days
  • On each command
    • If MAU event wasn’t sent in the last 30 days → Send MAU event
    • If MAU event was already sent in the last 30 days → Skip MAU event
5 Likes
2

It would be useful to know what people actually use, in other contexts as well. Will the exit code (just success/failure) be captured as well so that it is possible to detect commands that are hard or confusing to use? Otherwise there might be a command that gets counted 10 times just because the user is struggling to get it to work. 9 failures + 1 success casts a very different light on those stats.

3

Yes, we’re going to report success/failure for each command invocation.

1 Like