Telemetry enhancement: Add "kill switch" for strict corporate environments

[psimsa]

While I understand and support the motivation behind SponsorLink, in order to be usable in many corporate environments it needs to provide ability to disable the telemetry.

Similar to how this is handled in .Net, where telemetry is on by default and you can disable it by setting environment variable, SL could provide similar functionality.

Proposal:

• As a first check, verify if there is an environment variable DISABLE_SPONSORLINK set to true. If so, terminate.
• Optionally, if the environment variable is set, SL can still display a diag message along the lines of "it sucks you don't want SL, but you probably have your reasons. you can still sponsor, btw."

That should satisfy many corporate security departments while still keeping the awareness up.

[iskiselev]

As currently it works with DOTNET infrastructure, it may be great to first check that customer opt out of DOTNET telemetry: DOTNET_CLI_TELEMETRY_OPTOUT. If it is set, use opt-in mechanics only, otherwise allow to opt-out of SL.

With it, for most customers it will still be active by default. For customers, that worry about telemetry data enough to opt-out Microsoft telemetry, it will not irritate them unless they explicitly allowed it.

[psimsa]

@iskiselev only thing is apparently from .net7 dotnet telemetry is opt-in, not opt-out. However, the analyzer can still display a diagnostics message when opted-out. The least of all evils to just raise the awareness.

[iskiselev]

@psimsa , after more research (https://learn.microsoft.com/en-us/dotnet/core/tools/telemetry, dotnet/sdk#14556, dotnet/sdk#25935) dotnet cli telemetry is still opt-out in all Microsoft builds and for source build (used by OS maintainers) it is disabled. I've not found any place that will say about opt-in.

[kzu]

I agree with @iskiselev that SL should follow whatever is set for DOTNET_CLI_TELEMETRY_OPTOUT first and foremost.

Also, telemetry should be entirely orthogonal with the sponsorship validation/verification. I'd even go as far as saying that telemetry should just follow the dotnet envvar and not even require a separate one (after all, if you don't trust MS for telemetry, why would you trust anyone else?). Although perhaps you might want to disable just SL? In that case, you'd most likely disable it entirely, and not just telemetry though?

So:

1. If DOTNET_CLI_TELEMETRY_OPTOUT, no SL telemetry whatesoever
2. If SPONSORLINK_OPTOUT (or similar), no SL telemetry neither sponsorship checking

I don't see a good scenario where you'd opt out of SL telemetry but still want the sponsoring check...

[iskiselev]

@kzu, if sponsorship validation would be reimplemented to not include any trackable information, it would really be orthogonal to telemetry. While sponsorship check is done by fetching any data from internet in a build, it still too similar to telemetry - just because it is possible to collect some information from network request, even if it does not include any PII. It still include IP address, so it is possible to say how often some IP builds SL-dependent projects - which is, in fact telemetry.

If SL check would be reimplemented (for example, all network request will be done by separately installed tool - while customer build will either use data already provided by tool or log message suggesting to install it) - in that case, telemetry and sponsorship checking would be really separate entities.

[kzu]

I've decided to drop telemetry for now see https://github.com/devlooped/SponsorLink/issues/34#issuecomment-1693466887. Hopefully this is something nuget itself can do better.