Disabling telemetry for a specific set of installations

[alhirzel]

With the telemetry changes (https://discourse.julialang.org/t/pkg-jl-telemetry-should-be-opt-in/42209), I feel there will be legitimate concern when Julia is used in commercial environments, especially when internal packages on an internal registry use external/public dependencies. To help manage these concerns, it would be best to build-in the capability to disable this telemetry across a set of PCs. Currently, it may be possible (albeit kludgy) to do with the existing documentation for the telemetry.toml file (https://julialang.org/legal/data/) and the /etc/skel directory for Linux and equivalent profile templates for Windows. My request is to make this easier.

One suggestion that is present in the Discourse is respect for the DO_NOT_TRACK environment variable (https://discourse.julialang.org/t/pkg-jl-telemetry-should-be-opt-in/42209/172).

Another possibility is clarifying the documentation currently provided on the referenced website (https://julialang.org/legal/data/) with a how-to for disabling telemetry for a given network. Ideally, this would look something like "redirect the telemetry.pkg.julialang.org domain to a black hole". As-suggested, this would require a change to the existing design so that telemetry data posts to a different domain.

[DilumAluthge]

I don't believe that this is necessary.

If you are in a commercial environment with security considerations, you can always set up your own Pkg server and use it by setting the environment variable:

export JULIA_PKG_SERVER="mypkgserver.example.com"

If you don't feel like setting up your own Pkg server, you can opt-out of all Pkg servers by setting the environment variable:

export JULIA_PKG_SERVER=""

If you opt-out of all Pkg servers, then all packages, artifacts, etc. will be downloaded from GitHub, GitLab, etc.

Therefore, because two very good options already exist, I don't think that this issue is necessary. In particular, I don't think that this issue should block Julia 1.5.

[alhirzel]

Hey, thanks for your reply! I agree that growing the scope of an internal registry is one way to disable telemetry reporting to public pkg servers, but this will increase overhead and reduce flexibility for commercial users (risk of negative perception as presented in JuliaLang/julia#36548).

I feel the suggestion is at-odds with the intent of having access to multiple registries (the intent of which I feel is to decrease tool friction when using publicly-registered packages). Also, I think that this issue reflects an opportunity to improve the telemetry design, because the suggestion amounts to duplicating or not using public registries while an opt-out option has already been created and documented.

I would appreciate comments/specific rationale for Pkg.jl not respecting the DO_NOT_TRACK environment variable, or any other more neutral environment variable such as JULIA_DISABLE_TELEMETRY, as I think this type of change would be easy (I can PR it if anyone would like) and feel it will resolve some of my concerns.

[DilumAluthge]

Hey, thanks for your reply! I agree that growing the scope of an internal registry is one way to disable telemetry reporting to public pkg servers, but this will increase overhead and reduce flexibility for commercial users (risk of negative perception as presented in JuliaLang/julia#36548).

Just FYI, opting out of Pkg server does not prevent you from using multiple registries or anything like that.

I would appreciate comments/specific rationale for Pkg.jl not respecting the DO_NOT_TRACK environment variable, or any other more neutral environment variable such as JULIA_DISABLE_TELEMETRY, as I think this type of change would be easy (I can PR it if anyone would like) and feel it will resolve some of my concerns.

I have no objection to either of those. I will let Stefan and/or Elliot speak to the feasibility/pros/cons of those options.