Revisit Telemetry configuration

[vcsjones]

Problem

There are a few issues around telemetry that are open today, such as #6145 and #6049.

I think it is safe to say that the ship has sailed on Telemetry and its default options, and what it collects. What I want to focus on is making it clear to understand what is going on and how to adjust it.

A current pain point of telemetry is that its opt-out experience is driven by an environment variable. This has to be done per-machine, and may not always be obvious how to do it in a persistent way for all accounts on a machine (I still forget how to do this across all various shells on macOS).

This can be troublesome in enterprises that need to be able to control these settings.

Proposal

User and System Configuration

Across supported platforms, there should be a user level and machine level telemetry option. For example, in Windows this might be a registry key in HKLM and HKCU, where HKCU is checked first, then falls back to HKLM, then falls back to default. For macOS, this could be a plist in ~/Library and /Library.

This allows organizations to configure telemetry via registry, which is a process they should already be familiar with. Same with plist files for macOS.

CLI configuration

There should be a dotnet telemetry command that changes the user-level configuration for telemetry. This allows people to make the change without trying to do this in .bash_profile, etc.

The environment variable should continue to be respected, and would probably "win" in all situations. So the order of preference is Environment Variable, User Config, Machine Config, Default.

[gortok]

I'll caveat this by saying that there are particular industries where this is especially problematic, and I think a minor tweak can be done to improve those issues.

By default, if you're invoking .NET Core for deployed Software, i.e, "dotnet MyApp.dll", that command should not collect telemetry.

In my particular use case (and this is a rather common one in industries where they aren't "SaaS" products, but rather Client Hosted solutions, the current setup means we need to ensure our Docker containers have a common line in them to set the environment variable correctly.

I understand that you want to see how developers use your product; but that's not the same as people who aren't developers -- people who should not be opted in (by default) to having metrics collected that can be used by nefarious actors (of course, you're only doing this over encrypted connections, right?)

[NickCraver]

I'm happy to provide my own telemetry. If it was opt-in, I would. But that's not the decision gone with here, so instead we'll deploy a GPO that disables it for everyone on our domain as we roll out the .NET Core tooling, simply because that's the simplest thing to safely do.

I sincerely hope the opt-in/out is re-visited. At the very least, this shouldn't require an environmental variable to opt-out, they're a PITA and impractical. I'm a fan of the dotnet telemetry command option above.

[richlander]

By default, if you're invoking .NET Core for deployed Software, i.e, 'dotnet MyApp.dll', that command should not collect telemetry.

This has always been the case. No change required.

Docker containers have a common line in them to set the environment variable correctly

If you use the runtime containers, which is recommended for production, then you don't have to do anything to disable telemetry as it isn't there/enabled.

GPO

That is interesting. It's an interesting q of whether we have GP APIs in .NET Core. I'll look into that.

dotnet telemetry

Also interesting as an option.

Meta -- I'm also not a big fan of env variables (for almost anything). They have served us OK to date. Certainly as .NET Core gets adopted into big business, we should look at some other options. Also, I could imagine how a more generic settings system might tie in with secrets management and such things.

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.