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?
I’m sympathetic to both the default distrust and to devs like you who want telemetry to improve their software and won’t use the data for anything else, but it is because of bad actors and enough dark ad patterns that we just can’t trust companies to play nice, and it’s too difficult to expect people to scrutinize each and every app or site individually. So I get why the default assumption is nefarious behavior.
But you’re totally right - telemetry & crash dumps & analytics are helpful & great for devs who care about the customer UX and don’t use the data for advertising or anything other than fixing & writing good software, so it’s a real kind of tragedy of the commons that we can’t have safe, trustworthy, and pro-consumer telemetry.
I went from building a web app that used Google Analytics and some other kinds of anonymous telemetry (and using that data only for identifying functional software & site issues), to building driver software that absolutely cannot send data out, and I wish for telemetry all the time. Not only is it difficult to understand what users are doing, they usually don’t even know themselves and can’t tell me what happened when things crash. The result is that turnaround times for critical issues are in months, when it could be days or hours if we had crash dumps and analytics, the lack of automated reporting hurts users.
I’m not sure there’s a way to separate the good from the bad, to designate some kinds of telemetry as safe and to be able to trust it while disallowing the stuff we don’t want. If that were somehow possible, if anyone has ideas, I would love to help figure out how to make it a reality.
The best way is to collect logs & crash reports locally, and if the app crashes you offer an option to send the report directly to you.
That's what I do in my apps. And it turns out, that actually increased the quality of the bug reports I got, because users were more invested and willing to cooperate.
Telemetry only tells you what users do, not why and doesn't explain their mental models. Try asking directly: open a discussion board (for example Github's Discussions) and encourage them to post about aspects of the software they found puzzling/annoying/inefficient. Take 15 minutes a week to go through the posts to see if anything attracts your attention.
Normal users don't register on a discussion board to tell about what went well during a normal day.
People only bother when something has made them really angry about something and need to vent.
This is why default analytics is the correct option. It gets the average people who don't care about forums and usually won't even bother to change many of the settings. The crowd who doesn't open HN first thing in the morning.
> Who's providing the telemetry/analytics if not one of same large corporations?
Erm. It would be me? The idea was that the app (not a web app btw) would send back data about which features were being used (to a server I control) so I could build up a picture of how often various features were being used relative to other features. Nothing remotely personally identifiable.
"I get the distrust of large corporations and other obvious bad actors - but the blanket cycnicism for all telemetry here is kind surprising"
There is effectively no way for a user to determine whether an actor is "bad" or "good" and that definition may vary depending on the user
The user cannot verify how the data might be used or where it might be transferred. As such, there is almost zero incentive for the data collector not to engage in malfeasance (as the user defines that term); deterrents are lacking
Perhaps there is irony in criticising "blanket" cynicism whilst arguing for "default" telemetry. Both suffer from the same "one size fits all" error
"Another idea was to have a prompt asking if you wish to upload the log or not, after every crash. Apart from the extra implementation time, players will still often click "Don't send", either because that's what they have been doing for many years or because they just want to quickly get back in the game or because they feel that the crash was somehow their fault."
Here, the developer is trying to infer user reasoning and intent
Curiously, he omits the possibility that users would prefer not to send the data
When in fact this is exactly what users indicate they prefer
He pretends that "Don't send" is ambiguous, for example, that despite clicking "Don't send" users actually don't care if data is sent
But there is nothing here that indicates users wanted to send data or that they do not care
Software developers can obviously do whatever they want and they can act against the interests of users
This includes ignoring or explaining away the preferences of their users ("Don't send") and engaging in speculation about user reasoning and intent
The developer here seems dismissive of users' reasons for clicking "Don't send", even though he does not know the reasons and can only speculate. At the same time he expects readers to take his reasons for collecting crash logs as justified. Then he unilaterally decides to remove user choice (the "Don't send" button) and substitute his own choice (send data) as a default
Perhaps lack of developer pre-release testing and quality control is relevant to this discussion. Alas, the problem is framed as one of data collection and user consent where the "solution" is making data collection surreptitious and making "consent" uninformed, implied
Perhaps because only way to get large sample size is to target users who are unaware of "defaults", i.e., remove choice
Perhaps when forced to make a choice ("opt-in"), users will not choose to share data (unless the developer uses dark patterns to manipulate the choice)
No offense, but if that's the case, you are very new to the discussion. It's been pretty well-documented that opt-out provides orders of magnitude more useful reports than opt-in.
For the best example: Factorio, a game with an almost-exclusively-technical playerbase and extremely well-regarded and community-friendly dev team, which already had a ton of people writing good bug reports on the forums, [fixed 12 crash-causing bugs](https://factorio.com/blog/post/fff-231) within two days after making crash reports automatic and opt-in.
And if it has that much impact for Factorio, you can imagine how much bigger the impact is for non-technical software.
I feel that I have been a victim of "good telemetry" too, as when advanced product features were removed which were probably not popular but that I personally relied on.
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 actually consider such a flag to be problematic. I don't want to give out any information - of course I never want to be tracked, but marking this via an ENV variable alone, already makes zero sense to me. I don't understand people who like that while claiming they do not want to be tracked; if they give that information, then this means they are marked.
Hmm. I read a semantic difference between "opt-out" and "being opted-in by default".
The first denotes an abstract policy, the second an action that has been done to you in which you were a passive participant. And this is all about our lack of agency.
You may prefer that we speak of abstract policies. But to say "there is no" about an otherwise sensible phrase implies that you think that we have agreed to stay within some fixed set of terminology. I didn't think that we had.
This flag is sent by my browser when I connect to SOMEONE ELSE’s SERVER.
The internet only took off because the primary business model which ran on ads and derivative information that servers do to their users.
It’s not fun. It’s not private or secure. It’s not illegal (in most jurisdictions for most industries). The flag exists as a response to the de facto and de jure state of the world, not some fairytale scenario.
> The internet only took off because the primary business model which ran on ads
No? It took off before advertising was widespread as a primary or sole funding business model? Also there's literally nothing about advertising that requires data collection about users. Sure they love to do it, and they might even believe that it helps their profits in some way. But it's not inherent, they got along just fine with billboards and newspaper classifieds. TV ads never required personal information. Not did pre roll cinema ads, or radio adverts. Nobody was bemoaning in the streets that they couldn't possibly find anything to buy
> This flag is sent by my browser when I connect to SOMEONE ELSE’s SERVER.
No, it's set in your command shell (e.g. bash) and tells CLI programs that support it to not connect to a server. It has nothing to do with browsers or ads. This is all very clear in the article.
Article quite literally talks about tracking of cli tools you run on your own computer, half of which are to pilot products that you pay with your own money.
Wow, I guess I grew up too close to actual cowboys that this is an interpretation I just never considered. Not sure why though as it's right there for the taking.
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...
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.
There's an inherent conflict. No one _wants_ to be tracked, there is no direct benefit to being tracked and only downsides. And advertisers want to track you. So there was no way to respect the flag other than making it obscure so only a few dedicated people turned it on.
I think getting ads that are relevant to me is better than compete nonsense. BUT, I also don’t want to give advertisers any information to do it. (Maybe A.S.L. is ok to share?)
Yes. I know my two thoughts are in conflict, for the advertisers. Too bad for them. Figure it out.
In other words, advertisers wrangled out of something that could help people because they claimed it wasn't the true intent of people?
Advertisers are the scum of the Earth, as someone with ADHD who doesn't ever consent to my attention being stolen in that way. I really don't care what their opinion is, since they're intruding into my headspace without permission
To play devils advocate there is a direct benefit to being tracked, at least theoretically search and ads will more relevant to you. I get no one wants ads but you do see ads here and there. It would arguably be better for you if everyone of them was relevant than not. Similarly search or even LLM answers could be better if the preferences of the asker are known
No, in not making excuses for tracking and I do lots of stuff myself of avoid being tracked
I’m only responding to the false premise that there are no benefits. There are. You can just choose to believe they aren’t worth the cost. I believe they aren’t but I have friends who opt into all tracking and even register their presence with multiple apps. They believe they’ll make more positive connections
Exactly. From my experience: the times I've found an ad relevant and worth clicking is about one-to-a-gazillion. Maybe relevance is higher for others but that still doesn't necessarily translate to real value. (ie. your life was improved in any way)
Also, this all presumes the targeting actually works and the current sea ads for shoes I just bought disagree with that. It's all just spam.
Microsoft is too sophisticated to plead ignorance; they are responsible for that outcome and I think we can assume they knowningly chose it. (Though now Microsoft browsers are such a small portion of the market that it doesn't matter.)
The biggest failure of DNT was browser makers - including Mozilla - removing it. It has zero performance impact (1 bit?) or development cost. As long as it was out there, when there was momentum against tracking, advocates had evidence of both demand for privacy and of trackers ignoring user wishes.
> advocates had evidence of both demand for privacy and of trackers ignoring user wishes.
This evidence both still exists and is also completely useless for anything. The more important consideration, by far, is that the DNT flag was actively harmful to users in the real world because, if it was acknowledged at all, it was used maliciously to help fingerprint and track users. There is no reason for browsers to continue providing to their users a toggle that not only misleads them about what will happen with the setting enabled, but actively contributes to the opposite outcome because we live in a world where being evil is the norm.
Lately, I've come across websites that instead of a cookie banner display a banner that states they recognize and honor my wish to not be tracked. Whether that really do or not is something I did not spend time looking into. The first time I saw it I thought it was a fluke, and then it happened a few more times with in a short time period. Couldn't tell you what sites they were though as it was just something from search results.
::shrug:: I set it a long time ago and never looked back. I never looked into it being deprecated, but I knew that pretty much everyone ignored it for reasons. But by these banners, I'm guessing it still lives on as a setting.
Advertisers ignored it because MS decided to turn it into opt-in instead of opt-out, and advertisers very much hate opt-in. They'd much rather require the most permissive defaults, and put every barrier they can in front of opting out.
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.
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.
One could also implement ALLOW_TRACKING as comma separated list for applications I choose to allow it. Say I would like to share telemetry with go and brew, but not aws and the rest ALLOW_TRACKING=go,brew
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.
HF is notorious for making it difficult to work offline (or at least not waste time trying to connect when everything needed is offline) and is constantly changing how it is being handled. Previously, there was TRANSFORMERS_OFFLINE, HF_DATASETS_OFFLINE, etc.
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.
DO_NOT_TRACK support doesn't mean tracking is not an explicit opt-in.
Example: the software crashes, and there is a crash handler that asks you if you want to send a crash dump. With DO_NOT_TRACK, the crash handler is disabled entirely, no question, no dump.
If it gets some adoption, that's probably how it will work. Those who have an financial interest in using tracking (ex: ads) probably won't support such an option.
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.
Not the person you are replying to, but I had the same thought come to mind. Every library and app seems to have its own way of disabling telemetry. In order for a unified way to actually result in unification, everyone has to sign onto it. Otherwise you now have DO_NOT_TRACK=1 for everyone who respects it in addition to all of the existing ways for everyone who does not respect it.
> 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.
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.
It didn’t go nowhere; a few projects implemented it. The philosophical basis was wrong, though.
Opt out should not be encouraged via an off switch. It should be eradicated, and the people who accepted money to write such malware should be plainly named so that such actions can be part of their professional reputation.
> It didn’t go nowhere; a few projects implemented it.
If you try to create a standard and almost no one implements it, it’s not a standard and it went nowhere. Its stated goal wasn’t achieved, and the fact its domain and webpage have been abandoned makes that abundantly clear.
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.
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.
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?
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.
Also every time you install a program Microsoft, Apple and Google knows depending on the device. For your safety of course. The tracking is so pervasive and the majority of people do not care.
Unfortunately there's no such thing as anonymous telemetry. There are multiple techniques to re-identify scrubbed data, and some [seemingly innocuous] data is inherently identifying.
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.
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).
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.
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
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?
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):
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.
And setting that env var should require a notarized consent to track contract that has an expiration of at most 60 days and has penalties of jail time for any data related to that telemetry, anonymized or not that is shared with a third party, for any reason, including but not limited to fulfilling the service the business purports to be providing.
It should be much more difficult to collect data than to opt out of collection.
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.
They expose to the developer that someone was using their software behind that IP address at that time. It also can frequently include private information. The events that occur on my computer are mine and do not belong to the developer of the software.
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.
Anyone on the path potentially learns something about your system and your software use.
Your IP during connection exposes your rough location.
Crash logs rarely are completely anonymized so both together can additionally serve as a way to re-identify the user.
The only way to properly transmit telemetry data would be Tor. And no, even then I don’t want my tools to report back my use. It’s simply not required, and data minimization is part of my set of ethics, and I’m happy that EU/GDPR sees it the same way. Not all data that you think is worth something to you is morally right to collect. You send data somewhere, even just to check for updates - ask me first. I do not want my hammer to report back how many nails I hammered in. I don’t want my software to reach out to the world without my consent.
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.
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.
Could you provide more details? Many applications use multiple processes, and use some intermittently. It seems like quite a bit of work to enumerate every process used and then to keep the white/blacklist updated as usage and software changes - every new application or command you use, every update, every OS change that affects networking or system calls etc ...
Yes, with security comes inconvenience, this is inevitable.
I'm not a daily user of network namespaces, and would probably write a script to do the configuration within a shell (it works a bit like containers). The configuration is inherited by child processes, so you only have to do it once. Basically whitelist the urls you typically use, and maybe let the script popup a dialog asking you to allow access when the firewall catches a domain that is not in the whitelist yet.
The reason the DNT header failed is because there is no way to enforce it. The browser can set the flag, but there's no way to ensure it's actually respected. There are no protocol police.
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.
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.
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.
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?
I’m sympathetic to both the default distrust and to devs like you who want telemetry to improve their software and won’t use the data for anything else, but it is because of bad actors and enough dark ad patterns that we just can’t trust companies to play nice, and it’s too difficult to expect people to scrutinize each and every app or site individually. So I get why the default assumption is nefarious behavior.
But you’re totally right - telemetry & crash dumps & analytics are helpful & great for devs who care about the customer UX and don’t use the data for advertising or anything other than fixing & writing good software, so it’s a real kind of tragedy of the commons that we can’t have safe, trustworthy, and pro-consumer telemetry.
I went from building a web app that used Google Analytics and some other kinds of anonymous telemetry (and using that data only for identifying functional software & site issues), to building driver software that absolutely cannot send data out, and I wish for telemetry all the time. Not only is it difficult to understand what users are doing, they usually don’t even know themselves and can’t tell me what happened when things crash. The result is that turnaround times for critical issues are in months, when it could be days or hours if we had crash dumps and analytics, the lack of automated reporting hurts users.
I’m not sure there’s a way to separate the good from the bad, to designate some kinds of telemetry as safe and to be able to trust it while disallowing the stuff we don’t want. If that were somehow possible, if anyone has ideas, I would love to help figure out how to make it a reality.
The best way is to collect logs & crash reports locally, and if the app crashes you offer an option to send the report directly to you.
That's what I do in my apps. And it turns out, that actually increased the quality of the bug reports I got, because users were more invested and willing to cooperate.
Telemetry only tells you what users do, not why and doesn't explain their mental models. Try asking directly: open a discussion board (for example Github's Discussions) and encourage them to post about aspects of the software they found puzzling/annoying/inefficient. Take 15 minutes a week to go through the posts to see if anything attracts your attention.
Normal users don't register on a discussion board to tell about what went well during a normal day.
People only bother when something has made them really angry about something and need to vent.
This is why default analytics is the correct option. It gets the average people who don't care about forums and usually won't even bother to change many of the settings. The crowd who doesn't open HN first thing in the morning.
> I get the distrust of large corporations and other obvious bad actors […]
> the blanket cynicism for all telemetry here is kinda surprising
Who's providing the telemetry/analytics if not one of same large corporations?
Many devs say they care about user privacy, but very few seem to care enough not to farm surveillance out to a 3rd-party they have no control over.
> Who's providing the telemetry/analytics if not one of same large corporations?
Erm. It would be me? The idea was that the app (not a web app btw) would send back data about which features were being used (to a server I control) so I could build up a picture of how often various features were being used relative to other features. Nothing remotely personally identifiable.
Opt-in data is "useless"
That's one I have not heard before
Useless for what
Targeting a certain "type of user" perhaps
"I get the distrust of large corporations and other obvious bad actors - but the blanket cycnicism for all telemetry here is kind surprising"
There is effectively no way for a user to determine whether an actor is "bad" or "good" and that definition may vary depending on the user
The user cannot verify how the data might be used or where it might be transferred. As such, there is almost zero incentive for the data collector not to engage in malfeasance (as the user defines that term); deterrents are lacking
Perhaps there is irony in criticising "blanket" cynicism whilst arguing for "default" telemetry. Both suffer from the same "one size fits all" error
"Another idea was to have a prompt asking if you wish to upload the log or not, after every crash. Apart from the extra implementation time, players will still often click "Don't send", either because that's what they have been doing for many years or because they just want to quickly get back in the game or because they feel that the crash was somehow their fault."
https://factorio.com/blog/post/fff-231
Here, the developer is trying to infer user reasoning and intent
Curiously, he omits the possibility that users would prefer not to send the data
When in fact this is exactly what users indicate they prefer
He pretends that "Don't send" is ambiguous, for example, that despite clicking "Don't send" users actually don't care if data is sent
But there is nothing here that indicates users wanted to send data or that they do not care
Software developers can obviously do whatever they want and they can act against the interests of users
This includes ignoring or explaining away the preferences of their users ("Don't send") and engaging in speculation about user reasoning and intent
The developer here seems dismissive of users' reasons for clicking "Don't send", even though he does not know the reasons and can only speculate. At the same time he expects readers to take his reasons for collecting crash logs as justified. Then he unilaterally decides to remove user choice (the "Don't send" button) and substitute his own choice (send data) as a default
Perhaps lack of developer pre-release testing and quality control is relevant to this discussion. Alas, the problem is framed as one of data collection and user consent where the "solution" is making data collection surreptitious and making "consent" uninformed, implied
Begs the question: Why isn't opt-out "useless"
Perhaps because only way to get large sample size is to target users who are unaware of "defaults", i.e., remove choice
Perhaps when forced to make a choice ("opt-in"), users will not choose to share data (unless the developer uses dark patterns to manipulate the choice)
Why is that
> That's one I have not heard before
No offense, but if that's the case, you are very new to the discussion. It's been pretty well-documented that opt-out provides orders of magnitude more useful reports than opt-in.
For the best example: Factorio, a game with an almost-exclusively-technical playerbase and extremely well-regarded and community-friendly dev team, which already had a ton of people writing good bug reports on the forums, [fixed 12 crash-causing bugs](https://factorio.com/blog/post/fff-231) within two days after making crash reports automatic and opt-in.
And if it has that much impact for Factorio, you can imagine how much bigger the impact is for non-technical software.
I feel that I have been a victim of "good telemetry" too, as when advanced product features were removed which were probably not popular but that I personally relied on.
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 actually consider such a flag to be problematic. I don't want to give out any information - of course I never want to be tracked, but marking this via an ENV variable alone, already makes zero sense to me. I don't understand people who like that while claiming they do not want to be tracked; if they give that information, then this means they are marked.
> 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.
It could also be used to prevent showing an opt-in notification at all even in software that requires opt-in.
It is a bit sad that in privacy enthusiastic consent is understood as failing to shout 'NO' in the right way.
Nitpicking: There is no being opted-in by default, that‘s opt-out
Hmm. I read a semantic difference between "opt-out" and "being opted-in by default".
The first denotes an abstract policy, the second an action that has been done to you in which you were a passive participant. And this is all about our lack of agency.
You may prefer that we speak of abstract policies. But to say "there is no" about an otherwise sensible phrase implies that you think that we have agreed to stay within some fixed set of terminology. I didn't think that we had.
If you hadn’t the option to go in it is not opt-in.
If so put you in by default but you have the option to go out it’s opt-put
So this is either opt-out or not a option at all
The law of the excluded middle does not create semantic problems for the phrase "being opted-in by default".
Human language does not work like that.
There is no excluded middle.
You have to turn it on = Opt-In
You have to turn it off = Opt-Out
Just because the option was added later on doesn’t change that.
Or tell me what’s the difference for me between Opted-In by default and Opt-Out
Do not track WHEN?
This flag is sent by my browser when I connect to SOMEONE ELSE’s SERVER.
The internet only took off because the primary business model which ran on ads and derivative information that servers do to their users.
It’s not fun. It’s not private or secure. It’s not illegal (in most jurisdictions for most industries). The flag exists as a response to the de facto and de jure state of the world, not some fairytale scenario.
> The internet only took off because the primary business model which ran on ads
No? It took off before advertising was widespread as a primary or sole funding business model? Also there's literally nothing about advertising that requires data collection about users. Sure they love to do it, and they might even believe that it helps their profits in some way. But it's not inherent, they got along just fine with billboards and newspaper classifieds. TV ads never required personal information. Not did pre roll cinema ads, or radio adverts. Nobody was bemoaning in the streets that they couldn't possibly find anything to buy
> The internet only took off because the primary business model which ran on ads and derivative information that servers do to their users.
quite the opposite I would argue:
https://nickyreinert.de/2020/2020-10-24-marketing-killed-the...
> This flag is sent by my browser when I connect to SOMEONE ELSE’s SERVER.
No, it's set in your command shell (e.g. bash) and tells CLI programs that support it to not connect to a server. It has nothing to do with browsers or ads. This is all very clear in the article.
You’re confusing the Internet with Google.
You can have ads without tracking.
Article quite literally talks about tracking of cli tools you run on your own computer, half of which are to pilot products that you pay with your own money.
Get off your high horse.
I would advocate for not getting your horse high to begin with, or hide your stash better.
Wow, I guess I grew up too close to actual cowboys that this is an interpretation I just never considered. Not sure why though as it's right there for the taking.
The article is about local desktop / CLI tools that collect telemetry, not the web browser "do not track" standard.
You can serve ads without tracking
> The internet only took off because the primary business model which ran on ads and derivative information that servers do to their users.
Arguable, on the other hand it did kill the internet. (or, almost so far, we'll see whether we rebound after decades of enshittification)
> This flag is sent by my browser when I connect to SOMEONE ELSE’s SERVER.
...and promptly, thoroughly ignored.
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...
https://toptout.me - exists and handles a lot of these problems, if not looking to create a new wheel.
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
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.
There's an inherent conflict. No one _wants_ to be tracked, there is no direct benefit to being tracked and only downsides. And advertisers want to track you. So there was no way to respect the flag other than making it obscure so only a few dedicated people turned it on.
> No one _wants_ to be tracked
Plenty of people seem to genuinely believe that “personalized ads” are good for them.
No-one is too absolute, but could ne used as a rough rule of thumb.
Depending on the study, 0.16% to 7% want to get tracked.
https://noyb.eu/sites/default/files/2025-07/Pay_or_Okay_Repo...
Lies, damned lies, and statistics
I think getting ads that are relevant to me is better than compete nonsense. BUT, I also don’t want to give advertisers any information to do it. (Maybe A.S.L. is ok to share?)
Yes. I know my two thoughts are in conflict, for the advertisers. Too bad for them. Figure it out.
They are told to believe that.
and yet if they had question prompted to them even most of them would click "no"
No, they don’t. They will click whichever option gets the modal out of the way.
In other words, advertisers wrangled out of something that could help people because they claimed it wasn't the true intent of people?
Advertisers are the scum of the Earth, as someone with ADHD who doesn't ever consent to my attention being stolen in that way. I really don't care what their opinion is, since they're intruding into my headspace without permission
To play devils advocate there is a direct benefit to being tracked, at least theoretically search and ads will more relevant to you. I get no one wants ads but you do see ads here and there. It would arguably be better for you if everyone of them was relevant than not. Similarly search or even LLM answers could be better if the preferences of the asker are known
No, in not making excuses for tracking and I do lots of stuff myself of avoid being tracked
I’m only responding to the false premise that there are no benefits. There are. You can just choose to believe they aren’t worth the cost. I believe they aren’t but I have friends who opt into all tracking and even register their presence with multiple apps. They believe they’ll make more positive connections
> theoretically > they believe
Exactly. From my experience: the times I've found an ad relevant and worth clicking is about one-to-a-gazillion. Maybe relevance is higher for others but that still doesn't necessarily translate to real value. (ie. your life was improved in any way)
Also, this all presumes the targeting actually works and the current sea ads for shoes I just bought disagree with that. It's all just spam.
Microsoft is too sophisticated to plead ignorance; they are responsible for that outcome and I think we can assume they knowningly chose it. (Though now Microsoft browsers are such a small portion of the market that it doesn't matter.)
The biggest failure of DNT was browser makers - including Mozilla - removing it. It has zero performance impact (1 bit?) or development cost. As long as it was out there, when there was momentum against tracking, advocates had evidence of both demand for privacy and of trackers ignoring user wishes.
> advocates had evidence of both demand for privacy and of trackers ignoring user wishes.
This evidence both still exists and is also completely useless for anything. The more important consideration, by far, is that the DNT flag was actively harmful to users in the real world because, if it was acknowledged at all, it was used maliciously to help fingerprint and track users. There is no reason for browsers to continue providing to their users a toggle that not only misleads them about what will happen with the setting enabled, but actively contributes to the opposite outcome because we live in a world where being evil is the norm.
Lately, I've come across websites that instead of a cookie banner display a banner that states they recognize and honor my wish to not be tracked. Whether that really do or not is something I did not spend time looking into. The first time I saw it I thought it was a fluke, and then it happened a few more times with in a short time period. Couldn't tell you what sites they were though as it was just something from search results.
GPC must be honored in California. https://oag.ca.gov/privacy/ccpa/gpc
According to https://www.didomi.io/blog/global-privacy-control-gpc-2026 it must also be honored in 11 other states but I'm not familiar enough with the specifics regarding those.
Just here to say yeah, I've seen this more of this lately- "The do-not-track signal has been followed" or somesuch.
Wow. I've never seen that. It would be great if it became more widespread.
But isn't DNT deprecated in most browsers? Maybe I misremember.
::shrug:: I set it a long time ago and never looked back. I never looked into it being deprecated, but I knew that pretty much everyone ignored it for reasons. But by these banners, I'm guessing it still lives on as a setting.
Advertisers ignored it because MS decided to turn it into opt-in instead of opt-out, and advertisers very much hate opt-in. They'd much rather require the most permissive defaults, and put every barrier they can in front of opting out.
Users usually don't know about or change settings, so opt-out often means little. What portion of users knows about DNT? 1% 0.1%
Microsoft knows that; they rendered DNT meaningless:
https://news.ycombinator.com/item?id=47990485
No, the advertisers were responsible for that outcome, by using that as a flimsy excuse to ignore the setting
Browsers only removed it once it was clear that the advertising industry was going to refuse to honor it
Global Privacy Control replaced Do Not Track.
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.
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.
One could also implement ALLOW_TRACKING as comma separated list for applications I choose to allow it. Say I would like to share telemetry with go and brew, but not aws and the rest ALLOW_TRACKING=go,brew
..and what kind of tracking, e.g. anonymous usage statistics vs update checks, e.g.
The specification could go on and on!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.
HF is notorious for making it difficult to work offline (or at least not waste time trying to connect when everything needed is offline) and is constantly changing how it is being handled. Previously, there was TRANSFORMERS_OFFLINE, HF_DATASETS_OFFLINE, etc.
Does something like Little Snitch catch these to help find the things doing hidden shenanigans?
Yes, it would flag an outbound connection from the Python process.
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.
DO_NOT_TRACK support doesn't mean tracking is not an explicit opt-in.
Example: the software crashes, and there is a crash handler that asks you if you want to send a crash dump. With DO_NOT_TRACK, the crash handler is disabled entirely, no question, no dump.
If it gets some adoption, that's probably how it will work. Those who have an financial interest in using tracking (ex: ads) probably won't support such an option.
i can't think of a single CLI that is possibly collecting analytics for ads
Most services are already collecting telemetry, them announcing support for it won't change that.
Well, don't look too deep else you won't be using many modern tools.
Hey, it's a list of services to feed fake data to!
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.
Better yet, don't allow such spyware crap on your computer.
pfft, just don't have a computer and you'll be good
Some hobbies are more fun than others.
That is the correct way of handling this.
Everyone proclaiming a "standard" is just adding to the long list of (unofficial) alternatives.
obligatory: https://xkcd.com/927/
how is this relevant?
Not the person you are replying to, but I had the same thought come to mind. Every library and app seems to have its own way of disabling telemetry. In order for a unified way to actually result in unification, everyone has to sign onto it. Otherwise you now have DO_NOT_TRACK=1 for everyone who respects it in addition to all of the existing ways for everyone who does not respect it.
right, thanks
"Everyone proclaiming a "standard" is just adding to the long list of "
The original creator of this standard has retroactively called it “a mistake”
https://git.eeqj.de/sneak/consoledonottrack.com/src/branch/m...
the original creator calls everyone implementing their standard a “scumbag” for having any form of analytics, which seems a bit of an overreaction
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:
For ilspycmd, for example, I had to defuse its default "update checking" behavior: 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.
Exactly, new “standard” won’t fix it
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.
> Default opt-in
This is called opt out.
Yeah, I always mix it up. Thank you!
For the record, Go’s telemetry is local by default (not uploaded): https://go.dev/doc/telemetry
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?
an LLM would do a fine job for most common things, doesn't really matter if a few of them get hallucinated
Same thing has been suggested a few years ago and it went nowhere.
https://web.archive.org/web/20200613155957/https://consoledo...
It didn’t go nowhere; a few projects implemented it. The philosophical basis was wrong, though.
Opt out should not be encouraged via an off switch. It should be eradicated, and the people who accepted money to write such malware should be plainly named so that such actions can be part of their professional reputation.
> It didn’t go nowhere; a few projects implemented it.
If you try to create a standard and almost no one implements it, it’s not a standard and it went nowhere. Its stated goal wasn’t achieved, and the fact its domain and webpage have been abandoned makes that abundantly clear.
This is the wrong way around. Software that tracks by default is malware.
just sinkhole the domains
https://dpaste.com/E7RZ34MVD
https://github.com/StevenBlack/hosts
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.
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.
This
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...
Exactly what I was thinking.
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?
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.
Also every time you install a program Microsoft, Apple and Google knows depending on the device. For your safety of course. The tracking is so pervasive and the majority of people do not care.
It’s already a law in Europe. GDPR and ePrivacy. You have to get consent from the user. Having worked for European companies, they take it seriously.
The assumption that telemetry is not allowed by GDPR is flawed
https://gdpr-info.eu/recitals/no-26/
Anonymous telemetry is allowed – and I don’t have a problem with that.
Unfortunately there's no such thing as anonymous telemetry. There are multiple techniques to re-identify scrubbed data, and some [seemingly innocuous] data is inherently identifying.
https://techcrunch.com/2019/07/24/researchers-spotlight-the-... | https://www.eff.org/deeplinks/2023/11/debunking-myth-anonymo...
I disagree with your premise (I’ve worked on anonymous telemetry and it can be done well.)
Not every company will do it well. Simpleanalytics.com seems to be one of the better ones.
But it’s still way better than the alternatives which don’t even try to be anonymous.
> We just want local software.
You just want local software to...send commands to your Cloud providers?
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.
Gathering information without real consent is shady.
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).
I applied it to PhotoStructure more than a year ago—I think it was when I first saw this on HN?
My point is that there *is* such a thing as software that tries to respect their users. I'm not the only one.
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.
If solution was real, it would be DO_TRACK=1, not the inverse.
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
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?
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
That's great, but isn't DNT deprecated?
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):
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
Here is a non comprehensive list of mine: https://makandracards.com/makandra/624560-disable-telemetry-...
Ooh thanks!
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.
And setting that env var should require a notarized consent to track contract that has an expiration of at most 60 days and has penalties of jail time for any data related to that telemetry, anonymized or not that is shared with a third party, for any reason, including but not limited to fulfilling the service the business purports to be providing.
It should be much more difficult to collect data than to opt out of collection.
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'm more thinking Python crashes, where you just get the lines that executed, and ~zero identifiable data.
They expose to the developer that someone was using their software behind that IP address at that time. It also can frequently include private information. The events that occur on my computer are mine and do not belong to the developer of the software.
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.
That's fair, thanks.
Anyone on the path potentially learns something about your system and your software use.
Your IP during connection exposes your rough location.
Crash logs rarely are completely anonymized so both together can additionally serve as a way to re-identify the user.
The only way to properly transmit telemetry data would be Tor. And no, even then I don’t want my tools to report back my use. It’s simply not required, and data minimization is part of my set of ethics, and I’m happy that EU/GDPR sees it the same way. Not all data that you think is worth something to you is morally right to collect. You send data somewhere, even just to check for updates - ask me first. I do not want my hammer to report back how many nails I hammered in. I don’t want my software to reach out to the world without my consent.
Consistency is key. I'd much rather set one global env variable than have to manage a dozen tool-specifc ones
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.
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.
You can also use network namespaces to simply block internet access for certain processes. It can even be finetuned with whitelists or blacklists.
Could you provide more details? Many applications use multiple processes, and use some intermittently. It seems like quite a bit of work to enumerate every process used and then to keep the white/blacklist updated as usage and software changes - every new application or command you use, every update, every OS change that affects networking or system calls etc ...
Yes, with security comes inconvenience, this is inevitable.
I'm not a daily user of network namespaces, and would probably write a script to do the configuration within a shell (it works a bit like containers). The configuration is inherited by child processes, so you only have to do it once. Basically whitelist the urls you typically use, and maybe let the script popup a dialog asking you to allow access when the firewall catches a domain that is not in the whitelist yet.
Is this how standards are formed today? Not RFCs, but registering domains for SEO?
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.
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
The reason the DNT header failed is because there is no way to enforce it. The browser can set the flag, but there's no way to ensure it's actually respected. There are no protocol police.
Privacy should be treated as a right, not something that can be abused for money. Love the idea of this
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'm old enough to remember Nancy Reagan just say no!I think this has the same effect.
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.
> We kind of need ublock origin on the operating system level
Totally agree! I've built a product doing exactly this in my previous job. I'm building something new & similar now, but much better :-)
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.
He’s better off vibecoding an include.sh that sets all the known do not track env vars for you.
It feels like this should be no_track, for consistency with no_color
https://xkcd.com/927/
This goes against user experience, doesn't it?
Why?
I’m morally opposed to the notion of optimizing the opt-out mechanism. I want a standardized opt-in mechanism, like:
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.> It’s their responsibility to get me to authorize their specific flavor of tracking.
And they do by burying it in the user agreement you probably agreed to.
Like it or not, it is your responsibility. I agree it shouldn’t be, but let’s be realistic.
Then it's my responsibility to feed them fake data.
They didn't opt out of my data, after all.
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.
Am I the only one who also finds it comical that rejecting cookies requires a cookie.
[dead]
[flagged]
[dead]
[dead]
[dead]