The issue is that it is not enforced. My version of My IP will tell you if 'Do Not track' and 'Global Privacy Control' are set by your browser but it is up to the website to honour your requests. Check if your browser is sending them by visiting: https://fshot.org/utils/myip.php
This is set up for the same fate as DNT in browsers. Collecting all the "do not track" env vars into a single "do_not_track.env" file, however, may not be a bad idea...
Love it. This is an annoying problem and likely the actual solution than asking folks to use a universal one. I'll put something together as a starting point.
Advertisers chose to ignore DNT because they claimed Microsoft making DNT enabled by default took agency away from the user. In reality, they probably weren't going to honor it anyway.
Looks like a helpful honeypot! Any tool that will public announce support for this spec is a tool I know to avoid because it collects telemetry without explicit opt-in in the first place.
I was surprised how hard it was to stop the Python transformers library from phoning home to Hugging Face. I set HF_HUB_DISABLE_TELEMETRY=1, and when I called Wav2Vec2CTCTokenizer.from_pretrained I explicitly passed local_files_only=True, but still I got got a warning about not having a valid HF_TOKEN. It wasn't until I stumbled upon HF_HUB_OFFLINE=1 that I'm somewhat confident that I'm not making outgoing connections to HF every time I load a wav2vec2 model from disk.
I wouldn't have realized this was happening at all if it weren't for the obnoxious HF_TOKEN warning.
> Many CLI tools, SDKs, and frameworks collect telemetry data by default.
Any of those are using a dark pattern and before exploring new ways to opt out you should look for and spend your energy on an alternative which respects your freedoms upfront.
It's probably easier to run your own DNS and blacklist the offending domains. There are good blacklists with millions of telemetry domains, e.g. https://github.com/hagezi/dns-blocklists.
I’m morally opposed to the notion of optimizing the opt-out mechanism. I want a standardized opt-in mechanism, like:
export ALLOW_TRACKING=telemetry,crash_dumps
and the absence of such a setting means “fuck off, don’t spy on me”. It’s not my responsibility to turn off apps wanting to track me. It’s their responsibility to get me to authorize their specific flavor of tracking.
Honest question, what's the problem with crash dumps that include no personal info? They just help make the software less buggy. I also don't see an issue with anonymized usage patterns (this feature was used X times this month, this one Y times, etc).
Can someone expound on what they see as a problem?
> Honest question, what's the problem with crash dumps that include no personal info?
In addition to the other response: crash dumps are difficult to anonymize, both because useful crash dumps include something like a minidump (or some other small alternative to a core file), and because even without that, any random information from a backtrace may be sensitive (e.g. a URL).
There's nothing wrong with saving a crash dump and giving the user control of whether to submit a bug report.
I would suggest that the default to enrolling people in supplying such information is the issue. In a world driven by surveillance capitalism, even "anonymous" data can be used for much broader purposes (think, for example, of when and where people are using tools geographically and at what times: you can start to track the behaviour of people in this way).
Users should never be opted in through usage alone of free or paid-for tooling to supply information that isn't part of the function of the tool. Where that is required for a service or product, you should opt-in explicitly, not implicitly.
Default opt-in tracking should be illegal and enforced with such fines and prison sentences, that companies wouldn't even dare to have anything remotely capable of tracking in the runtime.
Unfortunately big corporations can always find away to make regulators see no problem.
Though if you just want a simple ENV var that handles this WHILE honoring the specification on this page: https://github.com/alloydwhitlock/do-not-track-cli
I wouldn't have realized this was happening at all if it weren't for the obnoxious HF_TOKEN warning.
Any of those are using a dark pattern and before exploring new ways to opt out you should look for and spend your energy on an alternative which respects your freedoms upfront.
Is anyone maintaining a more complete list of those?
Everyone proclaiming a "standard" is just adding to the long list of (unofficial) alternatives.
export SEMGREP_SEND_METRICS=off export COLLECT_LEARNINGS_OPT_OUT=true export STORYBOOK_DISABLE_TELEMETRY=1 export NEXT_TELEMETRY_DISABLED=1 export SLS_TELEMETRY_DISABLED=1 export SLS_NOTIFICATIONS_MODE=off export DISABLE_OPENCOLLECTIVE=true export NPM_CONFIG_UPDATE_NOTIFIER=false
Can someone expound on what they see as a problem?
In addition to the other response: crash dumps are difficult to anonymize, both because useful crash dumps include something like a minidump (or some other small alternative to a core file), and because even without that, any random information from a backtrace may be sensitive (e.g. a URL).
There's nothing wrong with saving a crash dump and giving the user control of whether to submit a bug report.
Users should never be opted in through usage alone of free or paid-for tooling to supply information that isn't part of the function of the tool. Where that is required for a service or product, you should opt-in explicitly, not implicitly.
Unfortunately big corporations can always find away to make regulators see no problem.