To track some of our history of adjusting telemetry/tracking:
- package level
- switch opt out default
- python-module: safety
- default value in flags switched
- python-module: safety
- force disabled
- bruno
- driftctl
- configurable, but only at build time
- also stops the version check which we quite often turn off too
- avalonia
- maptool
- not configurable beyond overriding build configuration
- seems just for error reporting
- switch opt out default
- service/module level
- setting available in config and default disabled
- ferretdb
- qdrant
- general
settings
attrset but default and example both havetelemetry_disabled = true;
- details on the telemetry - https://qdrant.tech/documentation/guides/usage-statistics/
- general
- code-server
- mattermost
- setting available in config and default disabled
This is a non-comprehensive list just what I put together over 40 mins. From what I can gather when we make an option available in a service as far as I can tell we always default to disabling it.
(Just to mention, in home-manager there are some general settings which give examples of disabling telemetry but don’t set anything by default)
It’s not going to be possible to track the packages & services which have telemetry and the maintainer is unaware, or which have telemetry and the maintainer purposefully left it’s default settings, or packages which have telemetry but are disabled default opt-in or at least ask the user upstream.
Some packages could be purposely left with telemetry enabled by default because it logs out “To disable telemetry do XYZ” during initial (or every) use.