Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Revisit Telemetry configuration #6086
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.
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
This allows organizations to configure telemetry via registry, which is a process they should already be familiar with. Same with
There should be a
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.
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, "
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?)
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
referenced this issue
Jul 27, 2017
This has always been the case. No change required.
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.
That is interesting. It's an interesting q of whether we have GP APIs in .NET Core. I'll look into that.
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.