New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit Telemetry configuration #6086

vcsjones opened this Issue Mar 21, 2017 · 3 comments


None yet
5 participants

vcsjones commented Mar 21, 2017


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

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 ~/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.


This comment has been minimized.

gortok commented Mar 21, 2017

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?)


This comment has been minimized.


NickCraver commented Mar 21, 2017

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.


This comment has been minimized.


richlander commented Jul 27, 2017

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.


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.

@livarcocc livarcocc added this to the Backlog milestone Feb 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment