Do_not_track (opens in new tab)

My projects could genuinely benefit from telemetry as I have no idea about usage patterns and my community (mainly artists) is not famous for maintaining a close dialogue with software developers.

I haven't bothered because a) opt-out risks a backlash and b) opt-in affects the data so much it becomes useless (much smaller sample and probably self-selecting a certain type of user)

Skimming the comments here, it seems everybody assumes telemetry is always nefarious. I get the distrust of large corporations and other obvious bad actors - but the blanket cynicism for all telemetry here is kinda surprising. Have none of the developers here ever had a need for it themselves?

It's interesting that we're so used to be tracked at this point that no one balks at being opted-in by default. A flag called DO_NOT_TRACK sounds like a good idea, but also suggests the default is CONSENT_TO_TRACK=1, and I find that creepy.

I always choose to go with positive terms with variables etc, so this would then be ALLOW_TRACKING=0. It brings in some consistence and makes it easier to reason, as you get to avoid double negation.

Perhaps the "DO NOT TRACK" name is somewhat of an established term, though.

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...

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.

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.

No. It shouldn't be an opt-out, and it is bad practice to write conditional settings in the negative.

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.

The original creator of this standard has retroactively called it “a mistake”

https://git.eeqj.de/sneak/consoledonottrack.com/src/branch/m...

I was worried about .NET sending telemetry once I found about the existence of the DOTNET_CLI_TELEMETRY_OPTOUT env.

Thankfully, the dotnet package installed by package manager on Arch Linux disables telemetry by default. I left the env set just in case.

But my trust towards "modern" software has lowered. I default to run CLI tools, especially those built in JavaScript or .NET with network disabled:

    firejail --net=none

For ilspycmd, for example, I had to defuse its default "update checking" behavior:

    alias ilspycmd='ilspycmd --disable-updatecheck'

This is what I'd call user-hostile defaults.

> 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.

For the record, Go’s telemetry is local by default (not uploaded): https://go.dev/doc/telemetry

Same thing has been suggested a few years ago and it went nowhere.

https://web.archive.org/web/20200613155957/https://consoledo...

The most useful part of this page is the list of optout commands to stick in my shellrc.

Is anyone maintaining a more complete list of those?

This proposal is really harmed by the name.

There is a reason none the existing methods use the word "TRACK". Although connecting home can be used for tracking it doesn't have to be.

If a tool uses connecting home for telemetry, implementing "DO_NOT_TRACK" would suggest it does track its users without the setting, even if it may not.

Rename it this to "DO_NOT_CONNECT_HOME" and it may be a useful standard.

The only way to force companies to stop mass tracking without consent is to flood them with fake tracking data. If enough people install noise generators for all opt-out trackers, opt-in becomes the only viable model.

Many of these tools are source available or supposedly open source, so it can't be that hard to take their tracking endpoints and call them in random order.

just sinkhole the domains

https://dpaste.com/E7RZ34MVD

https://github.com/StevenBlack/hosts

If any org had any use for telemetry they'd have no incentive into to adhere to something that would make it easier for users to opt-out. In fact that thee whole reason you have to opt-out instead of opt-in in the first place.

Its an ok solution, but will never be implement and doing it actively goes against the interest of those who would have to do implement it.

It worked so well on the browser already

I thought it would be a sh script to automatically set the flags for all known do not track env vars.

Given the URL and list of different opt-outs I thought this was going to be a shell script to set all these for you. In fact, I've just had an idea...

While we wait for companies to very very slowly implement that proposal, is there a place that collects in one place all the opt out methods for most common tools in one place? Perhaps even a shell module that sets them and regularly updates its list?

> We just want local software.

You just want local software to...send commands to your Cloud providers?

I don't think there is any way to stop people from tracking you. Technically speaking, you can pretty much always be tracked. Even if you eliminated all third party requests you could still be tracked. Downloads, logins, queries, etc all can be tracked. Virtually all software now has the "continuously upgrade to the latest version" bullshit so you are tracked every time you open the app. Even if you turn it off, they stop the app from working until you upgrade, so they force you to be tracked.

I think the only solution is to make it law that you can't track anyone for any reason without their consent, and can't sell consensual tracking data without an additional consent agreement. It would be a huge blow to the advertising industry, so it will never be made law, but it's the only thing that would work.

I doubt any vendor would apply this. It's not in their interest. Maybe a better solution would be to have a package that's always updated and provides a list of injected env vars for each vendor. One line in zshrc or bash and you're covered (at least for those who offer a way to disable the telemetry through an env var).

Consistency is key. I'd much rather set one global env variable than have to manage a dozen tool-specifc ones

The comments were interesting to look at: how a non-zero amount of people didn't click the link yet went on to write stuff about web's DNT. They are just browsing the headlines. Useful to populate own blocklist of people to ignore. At least we know these aren't bots. Or do we?

A GLOBAL do not track on the browsers works largely cause the target is all the websites being browsed and the tracking associated with it for advertising purposes. However telemetry is altogether a different thing, blocking it by default can be one idea, however using one standard variable to express the intent for all the tools is not practically viable

If solution was real, it would be DO_TRACK=1, not the inverse.

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 just sad. Luckily I do not use any of the listed programs. I threw out Homebrew many years ago when they started this nonsense.

The only tool I have installed currently that does %/"($& like this is Deno (required for yt-dlp now). It phones happily home even if you wrap it into a wrapper script that forces the env variable (in no way I'll pollute my default environment with stuff like this):

    $ cat /usr/local/bin/deno
    #!/bin/sh
    exec env DENO_NO_UPDATE_CHECK=1 /usr/local/packages/deno/latest/bin/deno "$@"

I wish bad dreams to whoever puts such crap into their software! Thankfully I have Little Snitch to catch most of those kind of invasions of my privacy.

Was wondering if there was a list of known opt outs as we are looking at a default opt out in Renovate[0] - we'll also look to set `DO_NOT_TRACK`

[0]: https://github.com/renovatebot/renovate/discussions/42932

Also this, we disable it when building or deploying apps in DollarDeploy

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

No, it should be a required (by law) opt-in TRACK_ME_I_DO_NOT_CARE_OR_AM_A_TEAPOT=418.

The proposed way just normalizes tracking.

Domain blocking is my preference but I would imagine that trackers probably also try to weed out data that contains racism, sexism, lewdness or some combination thereof. People can get very creative with ASCII art. AI surely does not accept such things.

Is this how standards are formed today? Not RFCs, but registering domains for SEO?

You can also use network namespaces to simply block internet access for certain processes. It can even be finetuned with whitelists or blacklists.

The reason browser's DNT header failed is that they don't want to user to turn off tracking by default

The reason they will not adopt common env is that because they do not want it to be easy to turn off

Love the idea but is an env var enough. Are there some sessions (docker?) that may not get it.

I'd prefer TRACK_ME as an opt in.

I'm old enough to remember Nancy Reagan just say no!I think this has the same effect.

Privacy should be treated as a right, not something that can be abused for money. Love the idea of this

I'd be interested in, 1. a SOME-TRUST model: a list of opt-outs for the known software that collect telemetry; so that I can just paste that into an env file and be done with it. 2. a ZERO-TRUST model [preferable]: where I control if an application can send any telemetry data; instead of depending on a flag that the distributor may or may not respect.

This goes against user experience, doesn't it?

It feels like this should be no_track, for consistency with no_color

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.

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.

I have some issue with how some of these are represented. For example, syncthing has an explicit opt-in request for telemetry / analytics. The suggested setting change is something entirely different - a call to ask what the latest version is. Granted, that server could log your IP address but that's no different to how it uses the relay and discovery servers that are also run by the same people - those could log the same way.

.. which is entirely different to the telemetry system where usage stats are reported. You can see that on data.syncthing.net. But again, thats a separate opt-in. The suggested env variable on the site won't turn that off.

I'm sure this will be about as effective as putting yourself on the do not call list for domestic phone telemarketers, which has absolutely no effect whatsoever on overseas scam call centers.

This does not make sense to support. Businesses that have proper privacy controls and security do not want to be lumped together with random shady apps and want users to explicitly opt out. Another issue with this header is that users could set it and then accidentally opt out of other sharing that they don't realize since this header is being set somewhere random. Standardizing on a per app basis way to revoke consent, along with showing privacy polices and measures the apps have put in place for guarding security would be a more sensible alternative that could gain traction.

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?

He’s better off vibecoding an include.sh that sets all the known do not track env vars for you.

Hi. I’m the one who made consoledonottrack.com (now expired and squatted) and originally specified and promoted this.

https://web.archive.org/web/20200613155957/https://consoledo...

I abandoned the project. Opting out of telemetry tells developers that opting us in automatically without consent is OK. It’s not.

Spyware is spyware even if it has an off switch.

Patch it out. Fork it. Don’t use spyware. Name and shame developers that accept pay checks to build spyware for corporations. Make it an economically bad choice to accept such jobs by poisoning the google results for the names of people who do this. Make them ashamed.

The one thing you DON’T want to do is validate their unethical model by opting out when you never opted in.

Am I the only one who also finds it comical that rejecting cookies requires a cookie.

Consent must be explicit, informed and can be revoked at any time.

Tech people could learn a lot from the BDSM community.

Tech companies regularly violate all 3 principles.

1) Opt-out instead of opt-in is an abusive practice, only you're not getting fucked by a strap-on without realizing it, you're getting profiled and manipulated for monetary and political gain.

2) You have no way to find out how your information is used. Ironic in an age where so many decisions affecting you are made by automated systems where the output can be traced back to individual inputs deterministically.

3) Even if you do your research (=spend your limited time alive by playing zero-sum games with no benefit for you) and opt-out, you can't take back what's already circulating out there.

And the solution is not that crazy - change laws so people own all data about them and all results of using said data, except specific well-defined cases.

Then if a company uses your data without your consent, it doesn't pay a probabilistic tax called fines, it is forced to give you a part of its income and a part of its own ownership.

I personally do not use this. The reason is quite simple: I do not want to give out ANY information to external sites. Meaning, they could want to group me into "wants to be tracked" and "does not want to be tracked". I expect a general content blocker, which ublock origin is, to protect me from any malicious external actor, including horrible UI, such as nowadays google search has. I mean, just make a regular google search and then ask yourself why google places so many ads. Yes, ALL links to videos on youtube are also google ads - they self-promote themselves here.

We kind of need ublock origin on the operating system level - even more so as the new laws mandate age sniffing of everyone, tied to usage and access to the www (see the concomitant fight against VPN; that is the long road here, the "but but but the children!" is the lie, the cake, the carrot on the stick).

Ultimately one could ask "but the do not track thing is harmless" - the issue still is that I don't agree that my browser should betray me. Naturally since Google controls most browsers, can we trust Google? But, even aside from Google, can we trust other browsers? We need more diversity here again, but also more quality on every level. I consider the do_not_track as actually a you_will_be_marked and thus tracked.