Do_not_track
Developers are tired of the privacy dance: a new DO_NOT_TRACK environment variable aims to standardize opting out of telemetry and tracking in CLI tools and SDKs. This proposal taps into a long-standing frustration within the Hacker News community about pervasive data collection and disparate opt-out mechanisms. The discussion quickly pivots to the historical failures of browser DNT and a fervent call for opt-in privacy by default.
The Lowdown
The DO_NOT_TRACK proposal introduces a universal environment variable designed to simplify the process of opting out of data collection in software. Currently, developers face a fragmented landscape where each CLI tool, SDK, or framework implements its own unique method for disabling telemetry, usage reporting, or crash reporting. This often leads to a complex and inconsistent privacy management experience.
The core of the proposal is straightforward:
- Standardized Opt-Out: A single
export DO_NOT_TRACK=1environment variable should signal a user's desire to disable all non-essential data transmission. - Comprehensive Scope: This includes ad tracking, anonymous or non-anonymous usage reporting, telemetry, crash reporting, and any other non-essential network requests to software creators or third parties.
- User Implementation: Users are advised to add this variable to their shell configuration files (
.bashrc,.zshrc, etc.) to ensure it applies across all terminal sessions. - Developer Action: Software authors are urged to check for this variable and respect it by disabling all tracking when set to
1. They are also encouraged to prioritize making telemetry opt-in rather than opt-out. - Inspiration: The proposal draws parallels with
NO_COLORandFORCE_COLORstandards, which streamline color output control in terminals.
Ultimately, DO_NOT_TRACK seeks to restore user agency over data collection, pushing for a world where software respects a clear, unambiguous signal to keep local interactions local.
The Gossip
DNT's Dubious Destiny
Many commenters expressed strong skepticism about the new `DO_NOT_TRACK` standard's effectiveness, frequently drawing parallels to the failed browser-based 'Do Not Track' header. The consensus is that if companies didn't respect DNT in browsers (often citing Microsoft's default-on DNT as a corporate excuse to ignore it), they're unlikely to respect an environment variable for CLI tools. The fear is that it merely normalizes the expectation of tracking rather than eliminating it.
Opt-Out vs. Opt-In Outcry
A dominant theme was the community's strong preference for an opt-in model for telemetry, rather than the proposed opt-out. Commenters argued that the default should be 'no tracking,' requiring explicit user consent (e.g., `export ALLOW_TRACKING=1`) before any data is collected. They view `DO_NOT_TRACK` as implicitly validating the current 'opt-out' dark pattern and believe privacy should be a fundamental right, not something users constantly have to fight to retain.
Circumventing Call-Homes
Instead of relying on a flag that might be ignored, several users suggested more robust, technical workarounds to prevent telemetry. These include leveraging DNS blacklists (e.g., Pi-Hole with large blocklists like `hagezi/dns-blocklists`), using network namespaces to block internet access for specific processes, or simply not installing software known for pervasive tracking. Some even maintain their own lists of `_OPTOUT` environment variables for a "SOME-TRUST" model.
Telemetry Troubles and Tales
Many shared personal frustrations with specific software making it exceedingly difficult to disable telemetry. Examples included the Python `transformers` library phoning home to Hugging Face despite multiple opt-out attempts, Deno's persistent update checks, and Homebrew's analytics. These anecdotes highlighted the real-world impact of scattered and often poorly implemented opt-out mechanisms, underscoring the pain point the `DO_NOT_TRACK` proposal aims to address.