Do_not_track

Original Article ↗ Hacker News Discussion ↗

A proposal to standardize a `DO_NOT_TRACK` environment variable for command-line tools has revived debate over how software should handle telemetry and user consent. Many commenters argue that any default-on tracking is inherently unethical and that opt-out mechanisms merely legitimize spyware-like behavior, preferring either strict opt-in, legal bans, or network-level blocking and sandboxing instead. Others note that telemetry and crash reports can genuinely improve software quality, but trust has been eroded by opaque data practices, weak enforcement of privacy signals like browser DNT, and the difficulty of ensuring that “anonymous” data stays anonymous.

Overall topic: CLI telemetry and a DO_NOT_TRACK env var

  • Thread discusses a proposed convention: tools honor a DO_NOT_TRACK (or similar) environment variable to disable telemetry / phoning home.
  • Focus is on local/CLI tools (package managers, frameworks, SDKs), not web browser DNT headers.

Perceived benefits and interest

  • Many like the idea of a single, standard opt-out flag for CLI tools.
  • Several want a curated list or script (include.sh, .env file, shell module) that sets all known telemetry opt-outs at once.
  • Some already use long lists of env vars in CI/build systems to disable telemetry across tools.
  • A few note existing helpers like centralized opt-out lists or small CLIs that set the proposed flag.

Criticisms of the proposal

  • Strong pushback against opt-out-by-default; many argue tracking should require explicit opt-in (e.g., ALLOW_TRACKING=…, TRACK_ME=1).
  • Concern that a standardized opt-out normalizes telemetry and implicitly approves tracking as the default.
  • Historical analogy: browser DNT failed because it was unenforceable and often ignored or even used for fingerprinting.
  • The original creator of an earlier console DNT proposal now calls it a mistake, arguing it legitimizes “spyware with an off switch.”

Alternative defensive strategies

  • Run own DNS or use large blocklists / sinkhole domains to stop telemetry endpoints.
  • Use host-based firewalls / tools (e.g., Little Snitch), network namespaces, containers, or sandboxes with --net=none.
  • Prefer tools that have no telemetry at all or are opt-in only; some users uninstall/avoid tools once hidden telemetry is found.

Debate on crash dumps and “anonymous” telemetry

  • Some see anonymized crash dumps and usage stats as harmless and helpful for fixing bugs.
  • Others argue:
    • Default enrollment is wrong even if data seems anonymous.
    • Crash data is hard to truly anonymize; stack traces, URLs, and IPs can be identifying.
    • “Anonymous telemetry” is often re-identifiable; GDPR and data-minimization ethics are invoked.

Telemetry’s value vs deep distrust

  • Some developers say telemetry would genuinely help understand usage and improve software, but:
    • Opt-out is seen as hostile.
    • Opt-in reduces sample size and introduces selection bias.
  • Others respond that pervasive abuse by large players makes broad trust impossible; users can’t realistically audit each app.

Naming, UX, and scope concerns

  • Several dislike negative flags (DO_NOT_TRACK) and prefer positive/whitelist style (ALLOW_TRACKING), possibly with granular scopes.
  • Some suggest a better name like DO_NOT_CONNECT_HOME to avoid implying all connections are “tracking.”
  • Questions raised about whether env vars reliably propagate (e.g., Docker, multi-process apps).
  • Some propose flooding telemetry endpoints with fake data as a long-term pressure tactic.

Regulation and enforcement

  • Multiple comments say any standard is weak without legal force; laws should mandate consent and restrict data sharing.
  • References to GDPR/ePrivacy: telemetry may be allowed if truly anonymous, but commenters dispute whether true anonymity is realistic.