25 ms·

Console Do Not Track – Proposal for a standard environment variable

668 points by thih9 5y ago

thih9 5y ago
This project looks especially relevant because of recent news about Audacity adding telemetry to their project [1] and because of the the community's reaction and a fork [2]. I feel like many people aren't aware that popular open source tools already collect usage data. [1]: https://news.ycombinator.com/item?id=27727150 https://news.ycombinator.com/item?id=27727150 [2]: https://news.ycombinator.com/item?id=27741910 https://news.ycombinator.com/item?id=27741910
cupofjoakim 5y ago
I support this fully and I'm very disappointed that the maintainers of these projects are hesitant to adopting it, many citing that they'd be interested only if other major players adopt it first. Cmon, it's such a minor change. Getting these PR's in means _you are_ a major player (atleast to some) and you might be able to drive change in a positive way. Why not jump on the opportunity?
- HappyTypist 5y ago
  Let's add some competitive pressure: start forking projects that don't support it.
  - chrisseaton 5y ago
    Have you got the time, expertise, and network to maintain Homebrew?
    - renewiltord 5y ago
      Considering the Homebrew PR they are so eager to merge was untested and won’t work according to the maintainer, I have some hypotheses.
      - dpcx 5y ago
        Looking at the code I can't see why it wouldn't work. It's an extra || condition. Can someone enlighten me?
        arp242 5y ago
        The maintainer just stated it without further explanation. Searching for "HOMEBREW_NO_ANALYTICS" does reveal some other references[1], and it seems that there are some other places where this may need to be added such as "Library/Homebrew/env_config.rb", but I don't know anything about homebrew. I do think it's very much a minimal-effort PR. It's hardly a PR at all: at the very least the tests and documentation should have been updated, and actually writing out some more rationale would help as well. I certainly wouldn't send a PR like this, at least not without the text "this is a proposal, and if accepted I will update the tests and documentation as well". [1]: https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYTICS https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYT...
        xyst 5y ago
        Probably the homebrew maintainers have hard coded usage of “HOMEBREW_NO_ANALYTICS”. The PR likely only fixes one instance. Lack of unit tests in PR support this hypothesis. Could be wrong though and the maintainer simply needed a vague excuse to not merge it. Haven’t completed a deep dive. I couldn’t be bothered to compare repository at the time of PR 2 yrs ago on mobile.
- noname120 5y ago
  This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-554317746 https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...
  - Hackbraten 5y ago
    Also: https://github.com/Homebrew/brew/pull/6745#issuecomment-554526607 https://github.com/Homebrew/brew/pull/6745#issuecomment-5545...
  - _jal 5y ago
    "You're not important. We might do this if you were someone who mattered." Sad to see such, ah, well-socialized people in open in source projects.
  - soraminazuki 5y ago
    From the link: > I would rather see the different packager managers sit together and work on that standard. And especially big players should get involved, like the debian/ubuntu apt people, the fedora people, the nixpkg people, pip, node and all the others. It’s almost as if any of the mentioned package managers has opt-out tracking code embedded in their CLIs.
    - wizzwizz4 5y ago
      To be fair, Debian has popularity-contest. (You have to install the package manually – or via a prompt in the installer; if you don't, you don't even have the tracking code on your system.)
      - kgwxd 5y ago
        THIS is the way telemetry should be. A completely separate opt-in only add-on. I don't trust flags, I've accidentally forgotten to check them myself countless time.
  - vultour 5y ago
    The best part of that discussion is how one Homebrew maintainer says "I'd like to see package managers implement this first", and when someone from Arch goes "we don't track at all" the big chief comes in and says "Run your package manager how you want/need and we'll do the same.". The guy also seems quite rude for someone with "Rude people blocker" in his bio.
- chrisseaton 5y ago
  These PRs are like bad dating app messages - they get threatening so quickly when the author is rejected.
- Igelau 5y ago
  Two reasons: 1) It's not a standard at all. Some guy made a webpage and used the word "we". Even in the GitHub issues there was debate about what having this variable set would mean (e.g. should a call to a formatting service be blocked). 2) One maintainer pointed out that being an early adopter would force them into advocacy that they aren't prepared to do. Judging from how argumentative Sneak was being, there's probably an element of "we don't want to be the vanguard for this bully and his variable"
ccsalvesen 5y ago
This is negative consent. I can't fathom why we are supposed to be ok with that. The variable should be named DO_TRACK.
- bouke 5y ago
  Indeed. And don’t such tools require GDPR consent to allow tracking or processing PII?
  - cupofjoakim 5y ago
    This is a great point actually - but it probably depends on if the data is regarded as "personal data" or not. IP-addresses is considered sensitive which would mean that if they're saving that it is probably not ok. I'm not a lawyer though :)
    - Anunayj 5y ago
      Storing IPs by themselves are not against the GDPR, and you do not really require consent for storing them for legitimate reasons, (Think nginx access logs, or rate limits on API endpoints/ banning IPs abusing your service). [1] Pairing IP addresses with other potentially identifying information can also be a little bit of a legal gray area (Look at Fingerprint.js) if done for legitimate reasons (Like fraud detection). Though honestly most users do not really care about the check box that says "I agree to give you access to all my personal information and sell it to everyone" when they click install, and it's such a sad situation. GDPR had a great potential, it's sad it was unable to do it's best. [1] https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/legitimate-interests/when-can-we-rely-on-legitimate-interests/#purpose_legitimate https://ico.org.uk/for-organisations/guide-to-data-protectio...
      - mschuster91 5y ago
        > GDPR had a great potential, it's sad it was unable to do it's best. Given the massive backlash against the GDPR and "cookie walls" by newspaper publishers, it's doing a pretty good job. Can you imagine a company like Apple whipping app vendors into shape regarding data collection without GDPR pressure?
mikl 5y ago
This is from 2019, should be flagged as such.
- steerablesafe 5y ago
  Good point, we should look at the state of those PRs then. For example the .NET PR is denied: https://github.com/dotnet/sdk/pull/17472#issuecomment-855087362 https://github.com/dotnet/sdk/pull/17472#issuecomment-855087...
agbell 5y ago
This is a great idea, but I feel like it needs an adoption and roll out strategy so that is starts to snowball. I think that opening PRS makes a lot of sense, but smaller projects or projects that don't yet have an opt-out mechanism are the most likely to adopt it in the early days I think. Then once you gather some momentum around those bigger projects might follow suit.
romanovcode 5y ago
This has been denied by big players such as .NET and Homebrew. This is a classic case of https://xkcd.com/927/ https://xkcd.com/927/
- detaro 5y ago
  What are the competing standards?
mercora 5y ago
i would think the only ones using this would be people who don't want to be tracked so setting this globally would be be great for them. However, what incentives would the products people see to have this implemented? i guess the same as for browsers...
wongarsu 5y ago
"PRs and Status" is a very optimistic headline for a list of rejected pull requests. I like the idea, but the execution leaves a lot to be desired. I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume. It's essentially a single person setting up a website, then submitting a bunch of untested pull requests to a bunch of projects. I imagine this would work much better if a large distro like Debian would adopt this first. They have the credibility and weight necessary for such a project, they can make it much more useful by asking for the desired setting during OS setup, and they can make sure it's universally respected via patches in the packaging process. From there it would have a chance at wide adoption.
- sneak 5y ago
  Chicken and egg problem, naturally. I'd love it to gain more traction. It was an idea and I thought it would be better an idea and a website than just an idea. It was strange to see it get labeled as a marketing attempt during my attempts to gain some traction, considering I'm not selling a damn thing. I have severe focus issues, so it had to be a one-day project unfortunately, which is why a couple of the patches weren't tested very well. Treasure your flow state when you get it. Ultimately I didn't invest any more time into it as developers who put default-on spyware in their apps don't actually want more people opting out. It's a doomed concept.
  - alpaca128 5y ago
    > It's a doomed concept. Indeed, because it assumes developers who are doing opt-out tracking will respect this voluntarily. I disagree with the poster above about Debian adopting this. They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo; in distros that already keep non-free software out of the standard repository this wouldn't be that much of a leap. This seems necessary, as there's no sign that a "please don't track me?" flag will work better in the terminal than it does now in the browser.
    - sneak 5y ago
      > They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo Debian maintainers are amazing and they go one step further: they patch it out when they distribute it. They also patch out old version time bombs and all manner of other phone-home.
varispeed 5y ago
It's crazy that we have to go through such lengths. Tracking should be opt in only. Tracking as opt out should be a criminal offence.
tomtomtom777 5y ago
It's a good idea but it seems to me the name will hurt adoption. Phoning home with telemetry data does not by definition imply tracking. Yet a project implementing DO_NOT_TRACK is essentially saying that without it, it is tracking users. This isn't particularly attractive for a project that already has some OPT_OUT_TELEMETRY option.
- sdflhasjd 5y ago
  I think this is closer to the real reason why so many of the maintainers were so combative about it. Too many of the reasons given by project maintainers seemed like irrelevant, roundabout ways of just saying "No, I don't like it"
- account42 5y ago
  > Phoning home with telemetry data does not by definition imply tracking. As far as the user can know for sure, it does.
naikrovek 5y ago
I'm sure everyone doing tracking of console programs is just chomping at the bit waiting for the creation of an easy-to-remember way for users to opt out... more useful would be something like this that lets users opt in or out of the various TYPES of tracking that are done. for example, I don't care about application usage telemetry. if you want to know that it's hard for me to remember a particular subcommand and am often looking up help for that subcommand, I don't care if you want know that. if you want to show me "we're hiring" horsepoo, well you can go away. opt out. same for "please donate, I'm not rich enough yet" messages. and straight ads can just die. options to tweak those things granularly would be welcome, if we're just daydreaming about things that will never get adopted.
- yunohn 5y ago
  > "please donate, I'm not rich enough yet" Who do you feel entitled enough to judge someone’s humble request for a donation, despite them developing the free software that you use often enough to be annoyed by it?
  - naikrovek 5y ago
    if they wanted to be paid, would they not release as a product, instead of releasing as open source? "hey I'm gonna give away my time and effort for free" is not how you get money. it's how you get geek cred or build up a resume or whatever. all fine, of course. do what you want. if you want to charge for your code, charge for it and stop asking for donations every time I clone or build your stuff. have a donation button somewhere so people CAN donate, of course. asking is very .. beggy and it drives me nuts, especially when it's from people who make $500k/yr at their day job.
    - yunohn 5y ago
      This is a very steamed and unfair rant; it really seems like you don’t understand how little FOSS work makes, and how little money is ever donated to most or any projects. I don’t know who hurt you in FOSS, but you sound really mean.
- 5y ago
seemslegit 5y ago
This is a losing proposition that will only lend credence to the inherently violent opt-out approach to data collection. Instead how about a do-not-hire-or-collaborate-with registry of the individual contributors participating in projects that employ those tactics and see how they like trying to opt out of it.
- sneak 5y ago
  That is another website on my to-do list: one that names and shames spyware developers who create these commits. Git blame writ large.
  - easterncalculus 5y ago
    Negative punishment will not work for this, you would be going after the symptom instead of the problem. Don't make it harder for people that write these changes, make it harder for people to force others to. There will always be another developer, and there's no guarantee you'll know their identities. If you're looking to bring attention and make a statement at the potential expense of others that's one thing, but practically speaking this approach can't work.
    - seemslegit 5y ago
      Practically speaking, that's the only approach that can. Although it's often hard to tell, most software developers aspire to being treated like professionals rather than specialized serfs, and part of being a professional is accepting responsibility for your work. Of course it doesn't preclude holding their employers responsible as well.
      - sneak 5y ago
        Netlify deleted my issue comment naming the developer who put `force: true` in their cli (sending a telemetry event when disabling telemetry) even though his name is still available in `git blame` in their public repo.
  - 5y ago
Cthulhu_ 5y ago
Of course, developers could say "Actually it's crash reporting, not tracking" or "Actually it's version checking, not tracking", so idk.
- TeMPOraL 5y ago
  I'm hoping some of those developers will have to explain this in more detail to a DPA processing a GDPR complaint against them.
theden 5y ago
Bad-actors would ignore it wholesale anyway, so this at best gives one a false sense of privacy. It would probably be better _not_ to have it, since people won't be misguided into thinking they're not being tracked. An actual effective approach to privacy is to use a firewall to block all unwanted connections (allowlist only), and a DNS sinkhole like pi-hole. IMO we should get more on the more aggressive side when it comes to mitigating tracking, and use tools that actually are a threat to the status quo. Tools like adnauseam[0] was blocked by Google[1] on their store because it actually worked—that says a lot more than a env var string they'll happily ignore. 0. https://adnauseam.io/ https://adnauseam.io/ 1. https://www.theregister.com/2017/01/05/adnauseam_expelled_from_chrome_web_store/ https://www.theregister.com/2017/01/05/adnauseam_expelled_fr...
- sneak 5y ago
  The approach I use is Little Snitch. It's how I discovered most of these telemetry misfeatures in the first place.
  - theden 5y ago
    I use LuLu https://objective-see.com/products/lulu.html https://objective-see.com/products/lulu.html a free, open source alternative. Was interested in little snitch but this has been working okay
  - aarchi 5y ago
    I’ve tried Little Snitch, but was quickly annoyed at the high interaction required. Maybe I should give it another shot, especially since I use uMatrix on Firefox, which is a similar concept.
    - kstrauser 5y ago
      It's overwhelming for the first couple of days, as periodic jobs wake up and ask for permission to connect to the Internet. Once you're over that initial hump, it basically disappears until some new app wants to connect to something unexpected.
  - 5y ago
mirekrusin 5y ago
Is there oh my zsh plugin or something that just exports all those envs?
vortico 5y ago
I doubt this will catch on. What's the incentive for the software companies to add it? I like the `source do-not-track.sh` idea better which defines a bunch of `WHATEVER_NO_TRACK := 1` variables. It could even modify config files for software that doesn't use environment variables. Or even better yet, just use a /etc/hosts file or a custom firewall.
- deleted 5y ago
  [deleted]
- jonnycomputer 5y ago
  What is the incentive for adopting the XDG Base Directory Specification?
bigus 5y ago
An alternative for this would be creating a small tool which enables all these variables while the DO_NOT_TRACK=1 is not adopted widely.
kissgyorgy 5y ago
From a use standpojnt; sure, this would be nice. But the developers of these tools probably don't want to do that, because now if it's opt-out it would be opt in by default. Also there it would be harder to allow tracking for individual tools only. This proposal is an example of narrow thinking. However come up with this, would like to opt-out easily as a user, which is understandable, but the world is more complicated like that.
forty 5y ago
The altertnative approach (and maybe more realistic from what I could see from the PR they opened) would be to compile a list of all those variables and build a file one could source to disable all known telemetry (it could include that variable and allow things to migrate progressively)
- sneak 5y ago
  Belt and suspenders: https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/root/etc/skel/Library/bashrc.d/100.disable-spyware.sh https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/ro...
  - sss111 5y ago
    thanks for making this!
    - sneak 5y ago
      You're welcome. I haven't updated it for Big Sur yet, hopefully that will happen this month.
- orra 5y ago
  That's a good idea; it doesn't require buy in from the tool developers.
  - jonnycomputer 5y ago
    But buy in is worth it. Consider the related issue of every damn app not respecting a users home directory and polluting it with every file. But that's a problem the XDG Base Directory Specification was designed to solve. And things are better now, though you often have to explicitly set the XDG variables to get some applications to respect the standard. But just having a standard pulls people and organizations in to follow it.
- unfletch 5y ago
  I had the same thought, and pulled this together this morning: http://github.com/rfletcher/cli-privacy http://github.com/rfletcher/cli-privacy
chinathrow 5y ago
Tracking should be opt-in, not opt-out. Period.
- megous 5y ago
  Restrictive firewall (or unsharing to an empty network namespace) helps with non-malicious apps - no network access except for apps that may need it. Anyway, tracking on Linux by normal userspace apps is just creepy. There's just too much access if you run these kinds of apps under your main user or let alone root, unlike browser based tracking that happens inside a limited sandbox.
rob_c 5y ago
Controversially id like them to collate what is being tracked and by who on the cmdline, a bit of naming and shaming (if warranted) might go a long way to making the need for this mute. Having used crash analytics to fix a production tool in the wild I would say _all_ tracking is not bad. But projects really need to be a little more up front about it.
- FroshKiller 5y ago
  No thanks to the command line reporting for me, some scumbag would just turn that itself into another advertising vector.
CJefferson 5y ago
This seems poorly specified to me. For example, it claims one of the banned things is 'automatic update phone-home'. However, for brew they are only trying to disable analyitics, brew will still "phone home checking for updates", and there is no way to disable that (at present). Personally, I'd want to see something more fine-grained. Personally I want automatic updates (at least notifications that one is available), I can't imagine using a package manager that didn't provide that.
bruce343434 5y ago
> Remember: in the right hands, an IP address is a physical location. Hmmmm, I doubt this. You'd need to be an insider at an (just the right) ISP or a government agency to turn it into an exact physical location.
- pjerem 5y ago
  Yup, so, in the right hands, which is either an insider at the right ISP or a government agency, an IP address is a physical location.
- sneak 5y ago
  Over a million people have a SECRET clearance in the USA.
TeMPOraL 5y ago
Sure. But I have a question: why? Why should we opt out of the telemetry? To me, this idea seems to not just be admitting defeat, it's ensuring defeat right from the start. Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. On a related note, I wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR violation. I wonder how much of existing telemetry already crosses the "informed consent" requirement threshold. I'll definitely be filing a complaint if I find a tool that doesn't ask for it when, by law, it should.
- 542458 5y ago
  Because massive chunks of the population will never turn it on not due to ideological commitment, but simply due to no knowledge that it exists. Furthermore, if we define “tracking” as broadly as “any crash reports and any checking for updates” that effectively means these features will not work, and the open-source maintainers will have a much harder time tracking down bugs and encouraging people to update to less buggy or more secure versions of their software. Why not simply fork or choose not to install code you don’t like, rather than forcing your beliefs about what does or does not constitute acceptable code on the developers?
  - account42 5y ago
    You are not entitled to crash reports - that applies to open source developers just as to anyone else. If you wan't crash reports, have some kind of wizard or command to submit them and point to that when a crash happens, but you must always gather informed consent before submitting that data.
    - beaconstudios 5y ago
      I like how games typically handle this; if the application crashes a dialog appears asking if you want to send a crash report, and often tells you what's included in said report.
      - 5y ago
toastal 5y ago
Though the links on this site are now dead and incorrect for the repository on GitHub, it is good to see the author moved their repo to self-hosted Gitea (https://git.eeqj.de/sneak/consoledonottrack.com https://git.eeqj.de/sneak/consoledonottrack.com). It would be hypocritical to be against tracking and then host one's code on Microsoft's GitHub. Even better they released a blog post in 2020 about why the repos were moved (https://sneak.berlin/20200307/the-case-against-microsoft-and-github/ https://sneak.berlin/20200307/the-case-against-microsoft-and...).
pleone 5y ago
Nice try, but kinda difficult to make it works with pr system. What about this https://github.com/beatcracker/toptout https://github.com/beatcracker/toptout ? You can opt-out from just one place.
- beatcracker 5y ago
  Author here, feel free to ask me anything. Btw, currently I have a huge backlog of telemetry to add, so I wouldn't mind some help. If anyone interested, have a look at the GitHub issues in this repo. The repo itself contains all docs and examples to get you started.
rq1 5y ago
A better idea would be to centralize all the "do not track" mechanisms in a single repo and shell script to be sourced. That way you don't rely on the counter-party willingness to check for your flag.
swiley 5y ago
The easiest "Do Not Track" is to stick with FSF approved software. I know it looks pseudo religious and a bit ridiculous but the more that happens the more I'm convinced they're actually right.
heurisko 5y ago
I think this is an OK idea. But I think it would have been better to post on mailing lists and contact people to get "buy in" rather than just opening up PRs. I also find the "respect" wording of the PRs a little presumptuous and probably caused some push-back.
trackerme 5y ago
DO_NOT_TRACK is forever tainted by it's initial Microsoft introduction and the massive opposition of the tech community at the time to this idea. Apache webserver to this day strips the DNT header in it's default config. Accepting DNT would imply that the tech community was wrong on this one, and that will never happen. So it's dead without a name change.
- jeroenhd 5y ago
  "Do not track" is a sensible default. Data sharing should always be opt-in, it's just good manners. It's the disrespect of tracking agencies and web developers that killed the concept.
- rb12345 5y ago
  No, the real reason is because it's trying to use an optional technical flag to enforce a social/political policy, and as such was doomed to failure from the start. If I recall correctly, the "tech community" was largely in favour of DNT, and anti-advertising in any case. The advertising industry, however, was not, so why bother implementing something that goes against their own interests? The only workable solution to that problem in practice is legal/political: legislation and sufficient regulatory abilities to effect compliance (i.e. GDPR/PECR and the like). In the end, the US stuck with permit-all-by-default and largely don't care, the EU/UK went deny-tracking-by-default with penalties to back it up. The reality is that this proposal will fail for much the same reasons: either you have an opt-in mindset from personal beliefs or legal requirements, in which case the global off-switch is worthless to you; or you're pro-tracking, in which case the incentives are to ignore the switch. Or you're Debian etc. and you remove the tracking code outright...
floatingatoll 5y ago
This seems dead on arrival, because Homebrew (as they reference on-page) by necessity contacts a wide array of remote addresses, giving away the user’s IP repeatedly as part of normal operation. That conflicts with redefining “track” to be different from the original meaning in the DNT header, to now extend to include any remote network connections at all - not just “do not compile a user profile from this network connection” but instead “do not divulge the existence of a user”. If this had restrained itself to the definition of tracking used by the original failed DNT effort, I might think very highly of it, but attempting to shoehorn the more stringent “offline by default” viewpoint into the framing stolen from DNT makes this proposal unlikely to be widely adopted. It’s really unfortunate that this good technical idea was combined with that overreach, as once the idea is rejected by others for going too far, any similar idea will likely be rejected without consideration. Oh well. Tangentially, do all the adblock extension users realize that their IP address is constantly divulged by all the rules updates their extensions are running in the background? This proposal would, if fully implemented through the entire software stack, result in browsers launched on the user’s machine refusing to allow any background network connections, which would break all ad blockers as they depend critically on that behavior. I’m not convinced that users prioritize “don’t divulge my IP address” over “block ads”, which seems to be a conceptual nail in the coffin of overreach here.
- jefftk 5y ago
  If you look at the PR they sent to Homebrew, they defined it as an alias for their existing flags for turning off analytics. That doesn't look like an overreach to me? https://github.com/Homebrew/brew/pull/6745/commits/f255f63d40da7e9d3acc13683315a9aab2ef540b https://github.com/Homebrew/brew/pull/6745/commits/f255f63d4...
  - floatingatoll 5y ago
    The overreach is in expanding the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising: http://paranoia.dubfire.net/2011/01/history-of-do-not-track-header.html http://paranoia.dubfire.net/2011/01/history-of-do-not-track-... Expanding that to mean “do not reveal the user’s IP address” is a significant expansion of the original meaning, having little to do with the protection against being individually tracked that the DNT header was designed for. Asking Homebrew to disable analytics has nothing to do with targeted advertising opt-outs, but supports the ideological goal of the authors in promoting their new idea that revealing the existence of the user is “tracking”. That expansion exceeds the scope of the definition of “tracking” as used to reference targeted advertising and marketing, something that is not applicable to the Homebrew project’s existing flag in any way. Attempting to promote their beliefs by aliasing those two concepts together - tracking protection against targeted advertising, versus disabling telemetry and auto update - is therefore overreach to me, especially when presented without this context to projects such as Homebrew and others in pull requests, and I think it will ultimately lead to their effort’s failure. To me, this is all a direct consequence of their attempt to ride the coattails of the failed DNT effort by reusing its key phrase “do not track”. They should have used a different name. In a few seconds, I can think of a pretty great one that still acronyms to DNT, so clearly creativity wasn’t the obstacle here. Instead they chose to anchor to “Do Not Track” and it’s too late now to change that. We’ll see what happens.
jefftk 5y ago
This proposal is from 2019, and does not seem to have been adopted by any of the projects they have sent PRs to.
Lapsa 5y ago
yeah, right... this gonna work.
WesolyKubeczek 5y ago
First, this is backwards. As many have pointed out, any and all telemetry should be opt-in, not opt-out, so the variable should be named YES_PLEASE_TRACK_THE_LIVING_SHIT_OUT_OF_ME, and if and only if is it equal to 1, should the data be collected. But what irks me more is this measly list of unsolicited PRs. Going over a list of projects where you are a nobody and inject yourself with your "improvements" there, with the implication that if you don't accept the PR, you're somehow an enemy, is far from being a good way to advertise your cause. I remember Alex Gaynor spamming a lot of projects with PRs to amend the documentation to use gender-neutral language, and I remember Coralina Ehmke carpet-bombing projects into accepting codes of conduct. No matter how noble your ideas are, mass-harassing people into accepting them is a major dick move.
- imiric 5y ago
  The thing is opt-in telemetry doesn't work. Few people will actively choose to enable it, even if they read the documentation and are aware of it. I think we should distinguish benign uses of telemetry from tracking that collects invasive details about the environment the app is running in. A popular CLI open source project I use has telemetry enabled by default. The authors are upfront about the data it collects and reference the source code for everyone to verify it. It collects generic things like the app version, operating system, CPU architecture, and a couple more datapoints about the app usage. The IP isn't logged, but is of course known at the time of submission. This data is not sold or used for any nefarious purpose, but mostly to track which app versions and which features are most commonly used so that development efforts can be better planned. And there is of course a CLI flag and environment variable to disable it. I'm perfectly fine with this level of telemetry, as long as the authors are open about what data is collected and how it's used. Making the app switch to opt-in would probably eliminate most submissions and would make it impossible to know how the app is used in the wild.
  - deleted 5y ago
    [deleted]
  - sneak 5y ago
    "Behaving ethically wouldn't work for us, so we decided to behave unethically" is not a legitimate viewpoint.
ztcfegzgf 5y ago
all the pull-requests mentioned on that webpage are from 2019 and 2020 and all were rejected (well, technically the last one is still open, with a comment pointing to an another place where it was rejected). the "get involved" link points to a page that does not exist.
jordemort 5y ago
It’s disappointing, although not entirely surprising, how some projects met this idea with outright hostility. It’s an extremely simple idea. It seems obviously correct to me and I’m not sure what benefit any further effort at discussion or standardization would bring.
- kasabali 5y ago
  > I’m not sure what benefit any further effort at discussion or standardization would bring. It'd allow them to come up with more bullshit excuses to not implement it, that's what.
helsinkiandrew 5y ago
From the pull requests submitted so far, I'd say this is dead in the water unless Debian or Redhat or someone with more clout start using it. https://consoledonottrack.com/#prs-and-status https://consoledonottrack.com/#prs-and-status Perhaps a more pragmatic solution would be a notrack package (probably just a shell script) that could be executed from your .profile and sets the app specific variables?
londons_explore 5y ago
Does anyone else here run a commercial service with do-not-track functionality? I have observed that users who enable do-not-track raise more support tickets and generate substantially less revenue than those who do not. To the extent that those users are a net negative to my service. Even counting referrals of users who do enable tracking, even with generous assumptions about the metrics I can't see due to lack of data. My tracking doesn't involve ads - this is pure analytics for reporting dashboards, crash analysis, etc. Are my findings unusual?
meesles 5y ago
Agreed with many other posters here - the execution was messy and definitely lacked the calm and collected attitude I'm used to seeing when looking at new standards being discussed. I was also unimpressed with the tone of the issues/PRs opened. As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people on bad behaviors. I definitely don't want to encourage ignoring issues and letting people get away with things, but in this context a change in attitude would have brought much more success IMO Also I found it really weird that this has just bubbled up to the front page when the original PRs for this project were opened in 2019[1]. Why is this popping back up now? [1] https://github.com/gatsbyjs/gatsby/pull/19528 https://github.com/gatsbyjs/gatsby/pull/19528
- Igelau 5y ago
  Someone probably went looking for telemetry opt-out stuff since the recent discussion of Audacity's telemetry and weird policy changes. Somehow they found this. Unfortunately, the way this guy conducted himself was terrible. His tone and behavior in the issues and insistence that it's a standard just because he made a webpage were really off-putting. I can see why no one was champing at the bit to endorse this.
  - sneak 5y ago
    Unfortunately, opt-outs are purely perfunctory, as these kinds of developers would prefer they not exist at all. I now believe there was little/no hope of getting this sort of thing adopted in any case. They don't want to make it easier to opt out; the opt out only exists to deflect blame.
- sneak 5y ago
  > As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people on bad behaviors. The majority of "getting someone else to do something" in our society is done with negative "coercion" (for lack of a better term) than positive. Most people go to work only because a policeman will come to their house and make them homeless at gunpoint if they don't. The percentage used to be even higher, but excommunication doesn't carry the sting it once did. Ultimately, the end result of all legislation and regulation of industry is the implied threat of negative consequences, up to and including state-sanctioned violence, for people who violate laws. Calling out bad behaviors is a common and traditional technique for getting new laws passed. Shame and bad PR is a powerful tool. Last November I shamed Apple into dropping unencrypted OCSP. Perhaps one day I can shame developers into not spying on their users without consent. Fact: the bad PR of shipping nonconsensual spyware is the only reason there is an opt-out lever at all. If we can amplify that, we can make it being enabled a default.
rkeene2 5y ago
I've attempted to convince maintainers in the past to not do user-hostile things [0]. They seem to think they are entitled to a record of how I use their software on my own systems. It's not clear to me why they would think this, but I think it is because you always get this if you offer software as a service and many people have been involved in working on these projects, despite the vast majority of software not being offered this way (indeed, 96% of IT is on-premises spend [1]). I think the people who have worked on these projects have carried this attitude of usage information is their information over to other domains, without realizing that they are different domains. [0] https://github.com/matthewmueller/joy/issues/79 https://github.com/matthewmueller/joy/issues/79 [1] https://siliconangle.com/2020/11/30/exclusive-aws-chief-andy-jassy-wakeup-call-cloud-adoption/ https://siliconangle.com/2020/11/30/exclusive-aws-chief-andy...
smcameron 5y ago
On linux you can use network namespaces to deprive the program of access to the network (shouldn't be necessary, but this is the world we live in.) $ sudo ip netns add jail # create a new net namespace with no access $ sudo ip netns exec jail /bin/bash # launch a root shell in the new namespace # su - your-normal-username # become non-root $ ping google.com # see if network is accessible? ping: unknown host google.com $ ifconfig -a lo Link encap:Local Loopback LOOPBACK MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) $ audacity & # See if you can track me without a network audacity... [1] 4284 $ _
- nickysielicki 5y ago
  I really hope that someday someone builds some proper UX around network namespaces for desktop Linux. It would not be all that difficult to implement something akin to Qubes if you made NetworkManager namespace aware and integrated with dbus-launch to start the applications in the desired namespace.
WhyNotHugo 5y ago
You know what else expresses lack of consent? Lack of consent. It’s very sad how this “you consent unless otherwise stated” ideology keep growing and growing. “We’re not spying on you, it’s just that you never expressed not wanting to be spied upon”. Here’s a very educational video on how giving consent works: https://youtu.be/oQbei5JGiT8 https://youtu.be/oQbei5JGiT8
- yosito 5y ago
  If we held tech companies to the same standards we hold for interpersonal relationships, most tech companies would be in prison.
- ryandrake 5y ago
  Silicon Valley software developers have a huge problem understanding consent. Look at most dialogs presented for things that companies want you to do: Do you want to enable Feature X? 1. Yes 2. Ask me again later. Somehow, "no" is just not in their vocabulary. Imagine if "Silicon Valley" was a guy asking a woman on a date, and the only options he understood were "yes" AND "ask again later".
- arp242 5y ago
  I did not consent to being talked to by a stranger earlier today. I did not consent to any replies on this comment that might follow. I did not consent to the music from my neighbour this afternoon. I did not consent to being barked at by my other neighbour's dog yesterday. I did not consent to a list of things longer than I care to name. It's all about expectations: consent for everything is unworkable. Equating some basic telemetry to rape is idiotic and offensive.
barbazoo 5y ago
I'm not sure "do not track" would even be the right terminology here. We want to prevent apps from calling home or calling some telemetry or error reporting endpoint, sure. But is that "tracking" in the same sense as we're being tracked from website to website? I'm not aware of any malicious use of that data yet so we might not want to throw them in the same group as google and other advertisers and user data aggregators. How about "enable telemetry" to also make it opt in rather than opt out?
- oytis 5y ago
  If a tool collects days on what command line arguments I use and how frequently (some people in the comments argued it's a useful thing), there is hardly a better word for it than tracking.
cestith 5y ago
This is a great idea, but I want it to go one step further. Some projects I do want to send some telemetry. It would help if there was a standard way to name environment variables or config entries across projects so I can predict what I need to change for each one without digging through docs. Perhaps a per-account dotfile that lists projects with 0, 1, or 2 depending on no data, limited subset / anonymous only data, or full data.
nkingsy 5y ago
Surveil everything. Homogenize culture. Individuality is a myth. If we want to survive on this planet we need to be ground down into uniformity. Global governance is a pipe dream, but cultural smoothing and pervasive surveillance is inevitable. Look what the alternative has done to us and embrace it.
KingMachiavelli 5y ago
People say that crash reports & telemetry are useful for developers. But I imagine that they also create a lot of work for developers they would not otherwise have. If a user cannot be bothered to open a ticket themselves or at least opt-in to telemetry to demonstrate the issue, then is it really an issue that developer's should fix? If a app crashes in the woods and no one bother's to report it then is it a bug? (Joking partly). For commercial apps the dynamic is a bit different since customer's can & do expect things to be fixed without any action on their part.
- crazygringo 5y ago
  A lot of bugs are hard to reproduce, occur only on certain OS's, etc. In these cases, filing a ticket is often pretty useless. What's needed are widespread stats to determine severity, frequency, correlations, etc. In fact, I'd say the Venn diagram of bugs that can be meaningfully reported in a ticket, versus those best detected through crash reports, is pretty small. So you need both. Why do you think developers shouldn't fix crashes? Shouldn't developers themselves decide what they want to fix?
fouric 5y ago
I do not support this idea. The differences between the things they all group together under one umbrella is wild - ads, usage reporting, automatic updates, and crash reporting are all very different things and it's actively harmful to control all of them with a single switch. At the very least, there should be two different switches - "ads" and "everything else". If you don't want telemetry or crash reporting, that's fine - you may not care about helping the developers of an open-source project improve their software and that's your personal choice. Similarly, you may want to manually install security patches, while I want them to be automatically installed so I have one less thing to worry about. There may even be some crazy person that wants ads. I don't, but I'm not going to try to take away their freedom to choose them, which is what this proposal would do - an all-or-nothing switch for non-essential network access. Give me granularity. There's no (user-facing) reason not to.
- Seirdy 5y ago
  Lots of people in the Free Software community think that programs should exist only to help the user, and should just do exactly what the user tells them to do and nothing else. I am one of those people. Showing ads, making network requests that aren't necessary to carry out the expected functionality, etc. all fall under violations of that principle. Some violations are worse than others, but I treat them the same way. It's on the developers of the software to make these settings granular and off-by-default. If I want to help a developer, I'll go out of my way to do it and flip one of those switches if that's what it takes. Personally, I don't think this goes far enough; I think programs should require explicit consent simply to connect to the network, and most should request permission to connect only to certain domains. But that's just me ;).
  - notatoad 5y ago
    >it's on the developers of the software to make these settings granular and off-by-default. why? privacy advocates in these discusssions always jump to this position and assume everybody is going to agree just because they've invoked the magic p-word. telemetry is useful, and most people don't really care enough to change the defaults one way or the other. assuming that "because privacy" is not an argument that will sway me, can you explain why i should default to the less-useful option just for the sake of appeasing the people most likely to change the defaults?
neiman 5y ago
Here, I fixed it for you. "Console DO Track: A proposed unified standard for opting IN for telemetry for TUI/console apps."
chairmanwow1 5y ago
This website strikes me nothing more than an idea that someone seems to be passing off as a movement. I feel like the negative reactions of the devs of the FOSS projects who got PRs from this person aren't that surprising. To me this doesn't seem to add that much value and I would probably bounce it from my project as well.
holtalanm 5y ago
my question here is: are we really concerned about console tools overreaching their telemetry? personally, I am not. I would love to know why others think this is some kind of huge issue, without a bunch of 'what-if' scenarios.
- maddyboo 5y ago
  I am. The terminal is one of the few places I am not being tracked. It’s also a portal into my most private data and activity, so if there’s one place I don’t want to be tracked, it’s here. I do not long for a future where the terminal ecosystem resembles the state of the greater internet with regards to privacy and tracking. We’ve collectively watched it happen to almost every other segment of technology in the past 20-odd years, so it’s not far fetched to believe it could happen here as well.
  - holtalanm 5y ago
    are there documented cases of these cli tools abusing their telemetry? are they entirely used to pinpoint performance issues and bugs within the tools that implement this telemetry tracking? if it is the former, i can see there being cause for concern. if it is the latter, this is just pure fear-mongering.
ConcernedCoder 5y ago
DONT_BE_EVIL=1
jagged-chisel 5y ago
> We will continue to support the opt out mechanism described here: ... You can, and ALSO support this new thing. Supporting one more env var if you already support one for this kind of functionality is easy and low risk.
- renewiltord 5y ago
  Then fork and maintain the feature, dude. It's open source. Everyone here wants someone else to do the work but they don't want to do any work.
kgwxd 5y ago
I've been wanting this for years. Why does this target console apps only? Everything should respect it. If I have it set, nothing should even nag me about opting in.
fomine3 5y ago
User tracking isn't purpose of telemetry, so the variable name is misleading.
jasonlotito 5y ago
The assumption should be that the user does not want to be tracked. A ENV stating that is pointless. Scripts that would adopt this are already respecting you by having you opt-in to tracking. It does nothing, and promotes opt-out as the preferred way of showing consent, which is decidedly wrong.
unfletch 5y ago
Another approach: http://github.com/rfletcher/cli-privacy http://github.com/rfletcher/cli-privacy Instead of hoping for various software projects to standardize on a single control, aggregate the various controls in one place, and make it easy to set them all at once.
camgunz 5y ago
Good lord. Please stop writing software that contacts servers I didn't ask it to contact and sends information I didn't ask it to send. It's extremely easy.
thingification 5y ago
Time for this again: https://xkcd.com/463/ https://xkcd.com/463/ What's the alternative? http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ for example (outdated but shows the principle): http://www.cs.jhu.edu/~seaborn/plash/html/ http://www.cs.jhu.edu/~seaborn/plash/html/
tsujp 5y ago
Would this have scope to be added to the XDG Desktop spec, at least on POSIX systems? Except of course, changed to opt-in: XDG_TELEMETRY_ON I'd never set it but at least it be an option for some.
- sneak 5y ago
  Developers who ship spyware are even less likely to switch to an opt-in model than they are to support a unified system that makes it easy to opt-out.
ramtatatam 5y ago
I'm probably amateur but until today I did not know `aws cli` sends telemetry data... It's probably one of those "terms and conditions" that are way too long to read them, so I'm only half pissed because I did not read it. Indeed, sending such data should be opt-in, NOT opt-out From today on I will ensure each and every CLI I use plays fair game. But actually what did I expect, since for Firefox telemetry data is on by default :/
jrochkind1 5y ago
opting out of checking for "updates" in homebrew would probably harm your homebrew use more than most users realize. You won't ever be getting new formulae etc.
kazinator 5y ago
> respect the following environment variable This is under-specified without giving a definition of environment variable. For the purpose of this choice, "environment variable" should have the broadest possible interpretation, referring to any relevant space that supports named configuration parameters: - UNIX or Windows environment variable - U-Boot or other boot loader variable. - Kernel parameter: e.g. ... root=/dev/sdb1 DO_NOT_TRACK=1 ... - URL parameter: https://domain.example/foo/bar&param=24&DO_NOT_TRACK=1&... Basically any configuration variable that is relevant in the specific context. Lower-level system software which executes before there are environment variables should not be off the hook.
- jefftk 5y ago
  Their proposal is for console apps, and gives the example "export DO_NOT_TRACK=1". They are talking about your first bullet, and not any of the others.
zomglings 5y ago
In Bugout, we have implemented a global do not track environment variable: export BUGGER_OFF=true If you set this variable, any tools collecting usage and crash reports using Bugout will not phone home with those reports. (You can also use BUGGER_OFF=yes, BUGGER_OFF=1, etc.)
dantondwa 5y ago
The reaction of homebrew [1] really makes me dislike the project. They just answered with bullcrap, instead of directly addressing the matter. [1] https://github.com/Homebrew/brew/pull/6745 https://github.com/Homebrew/brew/pull/6745
oytis 5y ago
It is so depressing that we need this thing in the first place. What next, CONFIG_DO_NOT_TRACK so that kernel modules don't send telemetry to hardware vendors? Adtech "ethics" (lack of thereof) has become a huge problem for the community.
lamby 5y ago
"It looks like you are writing a letter^W^W^Wexperiencing a systemic problem. Would you like an individualised solution to that?"
kuba-orlik 5y ago
I think that this approach kind of dissolves the power of the word "consent" > plainly and unambiguously expresses LACK OF CONSENT by a user in GDPR terms, consent can never be assumed. In order to be valid, the consent has to be a result of a conscious, explicit action from the user. Things that are opt-out cannot use "consent" as a legitimizing premise

668 points by thih9 5y ago

This project looks especially relevant because of recent news about Audacity adding telemetry to their project [1] and because of the the community's reaction and a fork [2]. I feel like many people aren't aware that popular open source tools already collect usage data. [1]: https://news.ycombinator.com/item?id=27727150 https://news.ycombinator.com/item?id=27727150 [2]: https://news.ycombinator.com/item?id=27741910 https://news.ycombinator.com/item?id=27741910

cupofjoakim 5y ago

I support this fully and I'm very disappointed that the maintainers of these projects are hesitant to adopting it, many citing that they'd be interested only if other major players adopt it first. Cmon, it's such a minor change. Getting these PR's in means _you are_ a major player (atleast to some) and you might be able to drive change in a positive way. Why not jump on the opportunity?

HappyTypist 5y ago
Let's add some competitive pressure: start forking projects that don't support it.
- chrisseaton 5y ago
  Have you got the time, expertise, and network to maintain Homebrew?
  - renewiltord 5y ago
    Considering the Homebrew PR they are so eager to merge was untested and won’t work according to the maintainer, I have some hypotheses.
    - dpcx 5y ago
      Looking at the code I can't see why it wouldn't work. It's an extra || condition. Can someone enlighten me?
      - arp242 5y ago
        The maintainer just stated it without further explanation. Searching for "HOMEBREW_NO_ANALYTICS" does reveal some other references[1], and it seems that there are some other places where this may need to be added such as "Library/Homebrew/env_config.rb", but I don't know anything about homebrew. I do think it's very much a minimal-effort PR. It's hardly a PR at all: at the very least the tests and documentation should have been updated, and actually writing out some more rationale would help as well. I certainly wouldn't send a PR like this, at least not without the text "this is a proposal, and if accepted I will update the tests and documentation as well". [1]: https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYTICS https://github.com/Homebrew/brew/search?q=HOMEBREW_NO_ANALYT...
      - xyst 5y ago
        Probably the homebrew maintainers have hard coded usage of “HOMEBREW_NO_ANALYTICS”. The PR likely only fixes one instance. Lack of unit tests in PR support this hypothesis. Could be wrong though and the maintainer simply needed a vague excuse to not merge it. Haven’t completed a deep dive. I couldn’t be bothered to compare repository at the time of PR 2 yrs ago on mobile.
noname120 5y ago
This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-554317746 https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...
- Hackbraten 5y ago
  Also: https://github.com/Homebrew/brew/pull/6745#issuecomment-554526607 https://github.com/Homebrew/brew/pull/6745#issuecomment-5545...
- _jal 5y ago
  "You're not important. We might do this if you were someone who mattered." Sad to see such, ah, well-socialized people in open in source projects.
- soraminazuki 5y ago
  From the link: > I would rather see the different packager managers sit together and work on that standard. And especially big players should get involved, like the debian/ubuntu apt people, the fedora people, the nixpkg people, pip, node and all the others. It’s almost as if any of the mentioned package managers has opt-out tracking code embedded in their CLIs.
  - wizzwizz4 5y ago
    To be fair, Debian has popularity-contest. (You have to install the package manually – or via a prompt in the installer; if you don't, you don't even have the tracking code on your system.)
    - kgwxd 5y ago
      THIS is the way telemetry should be. A completely separate opt-in only add-on. I don't trust flags, I've accidentally forgotten to check them myself countless time.
- vultour 5y ago
  The best part of that discussion is how one Homebrew maintainer says "I'd like to see package managers implement this first", and when someone from Arch goes "we don't track at all" the big chief comes in and says "Run your package manager how you want/need and we'll do the same.". The guy also seems quite rude for someone with "Rude people blocker" in his bio.
chrisseaton 5y ago
These PRs are like bad dating app messages - they get threatening so quickly when the author is rejected.
Igelau 5y ago
Two reasons: 1) It's not a standard at all. Some guy made a webpage and used the word "we". Even in the GitHub issues there was debate about what having this variable set would mean (e.g. should a call to a formatting service be blocked). 2) One maintainer pointed out that being an early adopter would force them into advocacy that they aren't prepared to do. Judging from how argumentative Sneak was being, there's probably an element of "we don't want to be the vanguard for this bully and his variable"

ccsalvesen 5y ago

This is negative consent. I can't fathom why we are supposed to be ok with that. The variable should be named DO_TRACK.

bouke 5y ago
Indeed. And don’t such tools require GDPR consent to allow tracking or processing PII?
- cupofjoakim 5y ago
  This is a great point actually - but it probably depends on if the data is regarded as "personal data" or not. IP-addresses is considered sensitive which would mean that if they're saving that it is probably not ok. I'm not a lawyer though :)
  - Anunayj 5y ago
    Storing IPs by themselves are not against the GDPR, and you do not really require consent for storing them for legitimate reasons, (Think nginx access logs, or rate limits on API endpoints/ banning IPs abusing your service). [1] Pairing IP addresses with other potentially identifying information can also be a little bit of a legal gray area (Look at Fingerprint.js) if done for legitimate reasons (Like fraud detection). Though honestly most users do not really care about the check box that says "I agree to give you access to all my personal information and sell it to everyone" when they click install, and it's such a sad situation. GDPR had a great potential, it's sad it was unable to do it's best. [1] https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/legitimate-interests/when-can-we-rely-on-legitimate-interests/#purpose_legitimate https://ico.org.uk/for-organisations/guide-to-data-protectio...
    - mschuster91 5y ago
      > GDPR had a great potential, it's sad it was unable to do it's best. Given the massive backlash against the GDPR and "cookie walls" by newspaper publishers, it's doing a pretty good job. Can you imagine a company like Apple whipping app vendors into shape regarding data collection without GDPR pressure?

mikl 5y ago

This is from 2019, should be flagged as such.

steerablesafe 5y ago
Good point, we should look at the state of those PRs then. For example the .NET PR is denied: https://github.com/dotnet/sdk/pull/17472#issuecomment-855087362 https://github.com/dotnet/sdk/pull/17472#issuecomment-855087...

agbell 5y ago

This is a great idea, but I feel like it needs an adoption and roll out strategy so that is starts to snowball. I think that opening PRS makes a lot of sense, but smaller projects or projects that don't yet have an opt-out mechanism are the most likely to adopt it in the early days I think. Then once you gather some momentum around those bigger projects might follow suit.

romanovcode 5y ago

This has been denied by big players such as .NET and Homebrew. This is a classic case of https://xkcd.com/927/ https://xkcd.com/927/

detaro 5y ago
What are the competing standards?

mercora 5y ago

i would think the only ones using this would be people who don't want to be tracked so setting this globally would be be great for them. However, what incentives would the products people see to have this implemented? i guess the same as for browsers...

wongarsu 5y ago

"PRs and Status" is a very optimistic headline for a list of rejected pull requests. I like the idea, but the execution leaves a lot to be desired. I can understand why some Homebrew devs think it's just an attempt from someone to pad their resume. It's essentially a single person setting up a website, then submitting a bunch of untested pull requests to a bunch of projects. I imagine this would work much better if a large distro like Debian would adopt this first. They have the credibility and weight necessary for such a project, they can make it much more useful by asking for the desired setting during OS setup, and they can make sure it's universally respected via patches in the packaging process. From there it would have a chance at wide adoption.

sneak 5y ago
Chicken and egg problem, naturally. I'd love it to gain more traction. It was an idea and I thought it would be better an idea and a website than just an idea. It was strange to see it get labeled as a marketing attempt during my attempts to gain some traction, considering I'm not selling a damn thing. I have severe focus issues, so it had to be a one-day project unfortunately, which is why a couple of the patches weren't tested very well. Treasure your flow state when you get it. Ultimately I didn't invest any more time into it as developers who put default-on spyware in their apps don't actually want more people opting out. It's a doomed concept.
- alpaca128 5y ago
  > It's a doomed concept. Indeed, because it assumes developers who are doing opt-out tracking will respect this voluntarily. I disagree with the poster above about Debian adopting this. They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo; in distros that already keep non-free software out of the standard repository this wouldn't be that much of a leap. This seems necessary, as there's no sign that a "please don't track me?" flag will work better in the terminal than it does now in the browser.
  - sneak 5y ago
    > They shouldn't adopt DO_NOT_TRACK, they should ban any package that does tracking by default from their repo Debian maintainers are amazing and they go one step further: they patch it out when they distribute it. They also patch out old version time bombs and all manner of other phone-home.

varispeed 5y ago

It's crazy that we have to go through such lengths. Tracking should be opt in only. Tracking as opt out should be a criminal offence.

tomtomtom777 5y ago

It's a good idea but it seems to me the name will hurt adoption. Phoning home with telemetry data does not by definition imply tracking. Yet a project implementing DO_NOT_TRACK is essentially saying that without it, it is tracking users. This isn't particularly attractive for a project that already has some OPT_OUT_TELEMETRY option.

sdflhasjd 5y ago
I think this is closer to the real reason why so many of the maintainers were so combative about it. Too many of the reasons given by project maintainers seemed like irrelevant, roundabout ways of just saying "No, I don't like it"
account42 5y ago
> Phoning home with telemetry data does not by definition imply tracking. As far as the user can know for sure, it does.

naikrovek 5y ago

I'm sure everyone doing tracking of console programs is just chomping at the bit waiting for the creation of an easy-to-remember way for users to opt out... more useful would be something like this that lets users opt in or out of the various TYPES of tracking that are done. for example, I don't care about application usage telemetry. if you want to know that it's hard for me to remember a particular subcommand and am often looking up help for that subcommand, I don't care if you want know that. if you want to show me "we're hiring" horsepoo, well you can go away. opt out. same for "please donate, I'm not rich enough yet" messages. and straight ads can just die. options to tweak those things granularly would be welcome, if we're just daydreaming about things that will never get adopted.

yunohn 5y ago
> "please donate, I'm not rich enough yet" Who do you feel entitled enough to judge someone’s humble request for a donation, despite them developing the free software that you use often enough to be annoyed by it?
- naikrovek 5y ago
  if they wanted to be paid, would they not release as a product, instead of releasing as open source? "hey I'm gonna give away my time and effort for free" is not how you get money. it's how you get geek cred or build up a resume or whatever. all fine, of course. do what you want. if you want to charge for your code, charge for it and stop asking for donations every time I clone or build your stuff. have a donation button somewhere so people CAN donate, of course. asking is very .. beggy and it drives me nuts, especially when it's from people who make $500k/yr at their day job.
  - yunohn 5y ago
    This is a very steamed and unfair rant; it really seems like you don’t understand how little FOSS work makes, and how little money is ever donated to most or any projects. I don’t know who hurt you in FOSS, but you sound really mean.
5y ago

seemslegit 5y ago

This is a losing proposition that will only lend credence to the inherently violent opt-out approach to data collection. Instead how about a do-not-hire-or-collaborate-with registry of the individual contributors participating in projects that employ those tactics and see how they like trying to opt out of it.

sneak 5y ago
That is another website on my to-do list: one that names and shames spyware developers who create these commits. Git blame writ large.
- easterncalculus 5y ago
  Negative punishment will not work for this, you would be going after the symptom instead of the problem. Don't make it harder for people that write these changes, make it harder for people to force others to. There will always be another developer, and there's no guarantee you'll know their identities. If you're looking to bring attention and make a statement at the potential expense of others that's one thing, but practically speaking this approach can't work.
  - seemslegit 5y ago
    Practically speaking, that's the only approach that can. Although it's often hard to tell, most software developers aspire to being treated like professionals rather than specialized serfs, and part of being a professional is accepting responsibility for your work. Of course it doesn't preclude holding their employers responsible as well.
    - sneak 5y ago
      Netlify deleted my issue comment naming the developer who put `force: true` in their cli (sending a telemetry event when disabling telemetry) even though his name is still available in `git blame` in their public repo.
- 5y ago

Cthulhu_ 5y ago

Of course, developers could say "Actually it's crash reporting, not tracking" or "Actually it's version checking, not tracking", so idk.

TeMPOraL 5y ago
I'm hoping some of those developers will have to explain this in more detail to a DPA processing a GDPR complaint against them.

theden 5y ago

Bad-actors would ignore it wholesale anyway, so this at best gives one a false sense of privacy. It would probably be better _not_ to have it, since people won't be misguided into thinking they're not being tracked. An actual effective approach to privacy is to use a firewall to block all unwanted connections (allowlist only), and a DNS sinkhole like pi-hole. IMO we should get more on the more aggressive side when it comes to mitigating tracking, and use tools that actually are a threat to the status quo. Tools like adnauseam[0] was blocked by Google[1] on their store because it actually worked—that says a lot more than a env var string they'll happily ignore. 0. https://adnauseam.io/ https://adnauseam.io/ 1. https://www.theregister.com/2017/01/05/adnauseam_expelled_from_chrome_web_store/ https://www.theregister.com/2017/01/05/adnauseam_expelled_fr...

sneak 5y ago
The approach I use is Little Snitch. It's how I discovered most of these telemetry misfeatures in the first place.
- theden 5y ago
  I use LuLu https://objective-see.com/products/lulu.html https://objective-see.com/products/lulu.html a free, open source alternative. Was interested in little snitch but this has been working okay
- aarchi 5y ago
  I’ve tried Little Snitch, but was quickly annoyed at the high interaction required. Maybe I should give it another shot, especially since I use uMatrix on Firefox, which is a similar concept.
  - kstrauser 5y ago
    It's overwhelming for the first couple of days, as periodic jobs wake up and ask for permission to connect to the Internet. Once you're over that initial hump, it basically disappears until some new app wants to connect to something unexpected.
- 5y ago

mirekrusin 5y ago

Is there oh my zsh plugin or something that just exports all those envs?

vortico 5y ago

I doubt this will catch on. What's the incentive for the software companies to add it? I like the `source do-not-track.sh` idea better which defines a bunch of `WHATEVER_NO_TRACK := 1` variables. It could even modify config files for software that doesn't use environment variables. Or even better yet, just use a /etc/hosts file or a custom firewall.

deleted 5y ago
[deleted]
jonnycomputer 5y ago
What is the incentive for adopting the XDG Base Directory Specification?

bigus 5y ago

An alternative for this would be creating a small tool which enables all these variables while the DO_NOT_TRACK=1 is not adopted widely.

kissgyorgy 5y ago

From a use standpojnt; sure, this would be nice. But the developers of these tools probably don't want to do that, because now if it's opt-out it would be opt in by default. Also there it would be harder to allow tracking for individual tools only. This proposal is an example of narrow thinking. However come up with this, would like to opt-out easily as a user, which is understandable, but the world is more complicated like that.

forty 5y ago

The altertnative approach (and maybe more realistic from what I could see from the PR they opened) would be to compile a list of all those variables and build a file one could source to disable all known telemetry (it could include that variable and allow things to migrate progressively)

sneak 5y ago
Belt and suspenders: https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/root/etc/skel/Library/bashrc.d/100.disable-spyware.sh https://git.eeqj.de/sneak/osx/src/branch/master/custompkg/ro...
- sss111 5y ago
  thanks for making this!
  - sneak 5y ago
    You're welcome. I haven't updated it for Big Sur yet, hopefully that will happen this month.
orra 5y ago
That's a good idea; it doesn't require buy in from the tool developers.
- jonnycomputer 5y ago
  But buy in is worth it. Consider the related issue of every damn app not respecting a users home directory and polluting it with every file. But that's a problem the XDG Base Directory Specification was designed to solve. And things are better now, though you often have to explicitly set the XDG variables to get some applications to respect the standard. But just having a standard pulls people and organizations in to follow it.
unfletch 5y ago
I had the same thought, and pulled this together this morning: http://github.com/rfletcher/cli-privacy http://github.com/rfletcher/cli-privacy

chinathrow 5y ago

Tracking should be opt-in, not opt-out. Period.

megous 5y ago
Restrictive firewall (or unsharing to an empty network namespace) helps with non-malicious apps - no network access except for apps that may need it. Anyway, tracking on Linux by normal userspace apps is just creepy. There's just too much access if you run these kinds of apps under your main user or let alone root, unlike browser based tracking that happens inside a limited sandbox.

rob_c 5y ago

Controversially id like them to collate what is being tracked and by who on the cmdline, a bit of naming and shaming (if warranted) might go a long way to making the need for this mute. Having used crash analytics to fix a production tool in the wild I would say _all_ tracking is not bad. But projects really need to be a little more up front about it.

FroshKiller 5y ago
No thanks to the command line reporting for me, some scumbag would just turn that itself into another advertising vector.

CJefferson 5y ago

This seems poorly specified to me. For example, it claims one of the banned things is 'automatic update phone-home'. However, for brew they are only trying to disable analyitics, brew will still "phone home checking for updates", and there is no way to disable that (at present). Personally, I'd want to see something more fine-grained. Personally I want automatic updates (at least notifications that one is available), I can't imagine using a package manager that didn't provide that.

bruce343434 5y ago

> Remember: in the right hands, an IP address is a physical location. Hmmmm, I doubt this. You'd need to be an insider at an (just the right) ISP or a government agency to turn it into an exact physical location.

pjerem 5y ago
Yup, so, in the right hands, which is either an insider at the right ISP or a government agency, an IP address is a physical location.
sneak 5y ago
Over a million people have a SECRET clearance in the USA.

TeMPOraL 5y ago

Sure. But I have a question: why? Why should we opt out of the telemetry? To me, this idea seems to not just be admitting defeat, it's ensuring defeat right from the start. Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. On a related note, I wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR violation. I wonder how much of existing telemetry already crosses the "informed consent" requirement threshold. I'll definitely be filing a complaint if I find a tool that doesn't ask for it when, by law, it should.

542458 5y ago
Because massive chunks of the population will never turn it on not due to ideological commitment, but simply due to no knowledge that it exists. Furthermore, if we define “tracking” as broadly as “any crash reports and any checking for updates” that effectively means these features will not work, and the open-source maintainers will have a much harder time tracking down bugs and encouraging people to update to less buggy or more secure versions of their software. Why not simply fork or choose not to install code you don’t like, rather than forcing your beliefs about what does or does not constitute acceptable code on the developers?
- account42 5y ago
  You are not entitled to crash reports - that applies to open source developers just as to anyone else. If you wan't crash reports, have some kind of wizard or command to submit them and point to that when a crash happens, but you must always gather informed consent before submitting that data.
  - beaconstudios 5y ago
    I like how games typically handle this; if the application crashes a dialog appears asking if you want to send a crash report, and often tells you what's included in said report.
    - 5y ago

toastal 5y ago

Though the links on this site are now dead and incorrect for the repository on GitHub, it is good to see the author moved their repo to self-hosted Gitea (https://git.eeqj.de/sneak/consoledonottrack.com https://git.eeqj.de/sneak/consoledonottrack.com). It would be hypocritical to be against tracking and then host one's code on Microsoft's GitHub. Even better they released a blog post in 2020 about why the repos were moved (https://sneak.berlin/20200307/the-case-against-microsoft-and-github/ https://sneak.berlin/20200307/the-case-against-microsoft-and...).

pleone 5y ago

Nice try, but kinda difficult to make it works with pr system. What about this https://github.com/beatcracker/toptout https://github.com/beatcracker/toptout ? You can opt-out from just one place.

beatcracker 5y ago
Author here, feel free to ask me anything. Btw, currently I have a huge backlog of telemetry to add, so I wouldn't mind some help. If anyone interested, have a look at the GitHub issues in this repo. The repo itself contains all docs and examples to get you started.

rq1 5y ago

A better idea would be to centralize all the "do not track" mechanisms in a single repo and shell script to be sourced. That way you don't rely on the counter-party willingness to check for your flag.

swiley 5y ago

The easiest "Do Not Track" is to stick with FSF approved software. I know it looks pseudo religious and a bit ridiculous but the more that happens the more I'm convinced they're actually right.

heurisko 5y ago

I think this is an OK idea. But I think it would have been better to post on mailing lists and contact people to get "buy in" rather than just opening up PRs. I also find the "respect" wording of the PRs a little presumptuous and probably caused some push-back.

trackerme 5y ago

DO_NOT_TRACK is forever tainted by it's initial Microsoft introduction and the massive opposition of the tech community at the time to this idea. Apache webserver to this day strips the DNT header in it's default config. Accepting DNT would imply that the tech community was wrong on this one, and that will never happen. So it's dead without a name change.

jeroenhd 5y ago
"Do not track" is a sensible default. Data sharing should always be opt-in, it's just good manners. It's the disrespect of tracking agencies and web developers that killed the concept.
rb12345 5y ago
No, the real reason is because it's trying to use an optional technical flag to enforce a social/political policy, and as such was doomed to failure from the start. If I recall correctly, the "tech community" was largely in favour of DNT, and anti-advertising in any case. The advertising industry, however, was not, so why bother implementing something that goes against their own interests? The only workable solution to that problem in practice is legal/political: legislation and sufficient regulatory abilities to effect compliance (i.e. GDPR/PECR and the like). In the end, the US stuck with permit-all-by-default and largely don't care, the EU/UK went deny-tracking-by-default with penalties to back it up. The reality is that this proposal will fail for much the same reasons: either you have an opt-in mindset from personal beliefs or legal requirements, in which case the global off-switch is worthless to you; or you're pro-tracking, in which case the incentives are to ignore the switch. Or you're Debian etc. and you remove the tracking code outright...

floatingatoll 5y ago

This seems dead on arrival, because Homebrew (as they reference on-page) by necessity contacts a wide array of remote addresses, giving away the user’s IP repeatedly as part of normal operation. That conflicts with redefining “track” to be different from the original meaning in the DNT header, to now extend to include any remote network connections at all - not just “do not compile a user profile from this network connection” but instead “do not divulge the existence of a user”. If this had restrained itself to the definition of tracking used by the original failed DNT effort, I might think very highly of it, but attempting to shoehorn the more stringent “offline by default” viewpoint into the framing stolen from DNT makes this proposal unlikely to be widely adopted. It’s really unfortunate that this good technical idea was combined with that overreach, as once the idea is rejected by others for going too far, any similar idea will likely be rejected without consideration. Oh well. Tangentially, do all the adblock extension users realize that their IP address is constantly divulged by all the rules updates their extensions are running in the background? This proposal would, if fully implemented through the entire software stack, result in browsers launched on the user’s machine refusing to allow any background network connections, which would break all ad blockers as they depend critically on that behavior. I’m not convinced that users prioritize “don’t divulge my IP address” over “block ads”, which seems to be a conceptual nail in the coffin of overreach here.

jefftk 5y ago
If you look at the PR they sent to Homebrew, they defined it as an alias for their existing flags for turning off analytics. That doesn't look like an overreach to me? https://github.com/Homebrew/brew/pull/6745/commits/f255f63d40da7e9d3acc13683315a9aab2ef540b https://github.com/Homebrew/brew/pull/6745/commits/f255f63d4...
- floatingatoll 5y ago
  The overreach is in expanding the original mission of DNT, which was to request that sites not harvest a user’s data for targeted advertising: http://paranoia.dubfire.net/2011/01/history-of-do-not-track-header.html http://paranoia.dubfire.net/2011/01/history-of-do-not-track-... Expanding that to mean “do not reveal the user’s IP address” is a significant expansion of the original meaning, having little to do with the protection against being individually tracked that the DNT header was designed for. Asking Homebrew to disable analytics has nothing to do with targeted advertising opt-outs, but supports the ideological goal of the authors in promoting their new idea that revealing the existence of the user is “tracking”. That expansion exceeds the scope of the definition of “tracking” as used to reference targeted advertising and marketing, something that is not applicable to the Homebrew project’s existing flag in any way. Attempting to promote their beliefs by aliasing those two concepts together - tracking protection against targeted advertising, versus disabling telemetry and auto update - is therefore overreach to me, especially when presented without this context to projects such as Homebrew and others in pull requests, and I think it will ultimately lead to their effort’s failure. To me, this is all a direct consequence of their attempt to ride the coattails of the failed DNT effort by reusing its key phrase “do not track”. They should have used a different name. In a few seconds, I can think of a pretty great one that still acronyms to DNT, so clearly creativity wasn’t the obstacle here. Instead they chose to anchor to “Do Not Track” and it’s too late now to change that. We’ll see what happens.

jefftk 5y ago

This proposal is from 2019, and does not seem to have been adopted by any of the projects they have sent PRs to.

Lapsa 5y ago

yeah, right... this gonna work.

WesolyKubeczek 5y ago

First, this is backwards. As many have pointed out, any and all telemetry should be opt-in, not opt-out, so the variable should be named YES_PLEASE_TRACK_THE_LIVING_SHIT_OUT_OF_ME, and if and only if is it equal to 1, should the data be collected. But what irks me more is this measly list of unsolicited PRs. Going over a list of projects where you are a nobody and inject yourself with your "improvements" there, with the implication that if you don't accept the PR, you're somehow an enemy, is far from being a good way to advertise your cause. I remember Alex Gaynor spamming a lot of projects with PRs to amend the documentation to use gender-neutral language, and I remember Coralina Ehmke carpet-bombing projects into accepting codes of conduct. No matter how noble your ideas are, mass-harassing people into accepting them is a major dick move.

imiric 5y ago
The thing is opt-in telemetry doesn't work. Few people will actively choose to enable it, even if they read the documentation and are aware of it. I think we should distinguish benign uses of telemetry from tracking that collects invasive details about the environment the app is running in. A popular CLI open source project I use has telemetry enabled by default. The authors are upfront about the data it collects and reference the source code for everyone to verify it. It collects generic things like the app version, operating system, CPU architecture, and a couple more datapoints about the app usage. The IP isn't logged, but is of course known at the time of submission. This data is not sold or used for any nefarious purpose, but mostly to track which app versions and which features are most commonly used so that development efforts can be better planned. And there is of course a CLI flag and environment variable to disable it. I'm perfectly fine with this level of telemetry, as long as the authors are open about what data is collected and how it's used. Making the app switch to opt-in would probably eliminate most submissions and would make it impossible to know how the app is used in the wild.
- deleted 5y ago
  [deleted]
- sneak 5y ago
  "Behaving ethically wouldn't work for us, so we decided to behave unethically" is not a legitimate viewpoint.

ztcfegzgf 5y ago

all the pull-requests mentioned on that webpage are from 2019 and 2020 and all were rejected (well, technically the last one is still open, with a comment pointing to an another place where it was rejected). the "get involved" link points to a page that does not exist.

jordemort 5y ago

It’s disappointing, although not entirely surprising, how some projects met this idea with outright hostility. It’s an extremely simple idea. It seems obviously correct to me and I’m not sure what benefit any further effort at discussion or standardization would bring.

kasabali 5y ago
> I’m not sure what benefit any further effort at discussion or standardization would bring. It'd allow them to come up with more bullshit excuses to not implement it, that's what.

helsinkiandrew 5y ago

From the pull requests submitted so far, I'd say this is dead in the water unless Debian or Redhat or someone with more clout start using it. https://consoledonottrack.com/#prs-and-status https://consoledonottrack.com/#prs-and-status Perhaps a more pragmatic solution would be a notrack package (probably just a shell script) that could be executed from your .profile and sets the app specific variables?

londons_explore 5y ago

Does anyone else here run a commercial service with do-not-track functionality? I have observed that users who enable do-not-track raise more support tickets and generate substantially less revenue than those who do not. To the extent that those users are a net negative to my service. Even counting referrals of users who do enable tracking, even with generous assumptions about the metrics I can't see due to lack of data. My tracking doesn't involve ads - this is pure analytics for reporting dashboards, crash analysis, etc. Are my findings unusual?

meesles 5y ago

Agreed with many other posters here - the execution was messy and definitely lacked the calm and collected attitude I'm used to seeing when looking at new standards being discussed. I was also unimpressed with the tone of the issues/PRs opened. As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people on bad behaviors. I definitely don't want to encourage ignoring issues and letting people get away with things, but in this context a change in attitude would have brought much more success IMO Also I found it really weird that this has just bubbled up to the front page when the original PRs for this project were opened in 2019[1]. Why is this popping back up now? [1] https://github.com/gatsbyjs/gatsby/pull/19528 https://github.com/gatsbyjs/gatsby/pull/19528

Igelau 5y ago
Someone probably went looking for telemetry opt-out stuff since the recent discussion of Audacity's telemetry and weird policy changes. Somehow they found this. Unfortunately, the way this guy conducted himself was terrible. His tone and behavior in the issues and insistence that it's a standard just because he made a webpage were really off-putting. I can see why no one was champing at the bit to endorse this.
- sneak 5y ago
  Unfortunately, opt-outs are purely perfunctory, as these kinds of developers would prefer they not exist at all. I now believe there was little/no hope of getting this sort of thing adopted in any case. They don't want to make it easier to opt out; the opt out only exists to deflect blame.
sneak 5y ago
> As an adult, one of the many lessons we learn is that if you want people to do something you want, you should be friendly, constructive, and positive - not calling out people on bad behaviors. The majority of "getting someone else to do something" in our society is done with negative "coercion" (for lack of a better term) than positive. Most people go to work only because a policeman will come to their house and make them homeless at gunpoint if they don't. The percentage used to be even higher, but excommunication doesn't carry the sting it once did. Ultimately, the end result of all legislation and regulation of industry is the implied threat of negative consequences, up to and including state-sanctioned violence, for people who violate laws. Calling out bad behaviors is a common and traditional technique for getting new laws passed. Shame and bad PR is a powerful tool. Last November I shamed Apple into dropping unencrypted OCSP. Perhaps one day I can shame developers into not spying on their users without consent. Fact: the bad PR of shipping nonconsensual spyware is the only reason there is an opt-out lever at all. If we can amplify that, we can make it being enabled a default.

rkeene2 5y ago

I've attempted to convince maintainers in the past to not do user-hostile things [0]. They seem to think they are entitled to a record of how I use their software on my own systems. It's not clear to me why they would think this, but I think it is because you always get this if you offer software as a service and many people have been involved in working on these projects, despite the vast majority of software not being offered this way (indeed, 96% of IT is on-premises spend [1]). I think the people who have worked on these projects have carried this attitude of usage information is their information over to other domains, without realizing that they are different domains. [0] https://github.com/matthewmueller/joy/issues/79 https://github.com/matthewmueller/joy/issues/79 [1] https://siliconangle.com/2020/11/30/exclusive-aws-chief-andy-jassy-wakeup-call-cloud-adoption/ https://siliconangle.com/2020/11/30/exclusive-aws-chief-andy...

smcameron 5y ago

On linux you can use network namespaces to deprive the program of access to the network (shouldn't be necessary, but this is the world we live in.) $ sudo ip netns add jail # create a new net namespace with no access $ sudo ip netns exec jail /bin/bash # launch a root shell in the new namespace # su - your-normal-username # become non-root $ ping google.com # see if network is accessible? ping: unknown host google.com $ ifconfig -a lo Link encap:Local Loopback LOOPBACK MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) $ audacity & # See if you can track me without a network audacity... [1] 4284 $ _

nickysielicki 5y ago
I really hope that someday someone builds some proper UX around network namespaces for desktop Linux. It would not be all that difficult to implement something akin to Qubes if you made NetworkManager namespace aware and integrated with dbus-launch to start the applications in the desired namespace.

WhyNotHugo 5y ago

You know what else expresses lack of consent? Lack of consent. It’s very sad how this “you consent unless otherwise stated” ideology keep growing and growing. “We’re not spying on you, it’s just that you never expressed not wanting to be spied upon”. Here’s a very educational video on how giving consent works: https://youtu.be/oQbei5JGiT8 https://youtu.be/oQbei5JGiT8

yosito 5y ago
If we held tech companies to the same standards we hold for interpersonal relationships, most tech companies would be in prison.
ryandrake 5y ago
Silicon Valley software developers have a huge problem understanding consent. Look at most dialogs presented for things that companies want you to do: Do you want to enable Feature X? 1. Yes 2. Ask me again later. Somehow, "no" is just not in their vocabulary. Imagine if "Silicon Valley" was a guy asking a woman on a date, and the only options he understood were "yes" AND "ask again later".
arp242 5y ago
I did not consent to being talked to by a stranger earlier today. I did not consent to any replies on this comment that might follow. I did not consent to the music from my neighbour this afternoon. I did not consent to being barked at by my other neighbour's dog yesterday. I did not consent to a list of things longer than I care to name. It's all about expectations: consent for everything is unworkable. Equating some basic telemetry to rape is idiotic and offensive.

barbazoo 5y ago

I'm not sure "do not track" would even be the right terminology here. We want to prevent apps from calling home or calling some telemetry or error reporting endpoint, sure. But is that "tracking" in the same sense as we're being tracked from website to website? I'm not aware of any malicious use of that data yet so we might not want to throw them in the same group as google and other advertisers and user data aggregators. How about "enable telemetry" to also make it opt in rather than opt out?

oytis 5y ago
If a tool collects days on what command line arguments I use and how frequently (some people in the comments argued it's a useful thing), there is hardly a better word for it than tracking.

cestith 5y ago

This is a great idea, but I want it to go one step further. Some projects I do want to send some telemetry. It would help if there was a standard way to name environment variables or config entries across projects so I can predict what I need to change for each one without digging through docs. Perhaps a per-account dotfile that lists projects with 0, 1, or 2 depending on no data, limited subset / anonymous only data, or full data.

nkingsy 5y ago

Surveil everything. Homogenize culture. Individuality is a myth. If we want to survive on this planet we need to be ground down into uniformity. Global governance is a pipe dream, but cultural smoothing and pervasive surveillance is inevitable. Look what the alternative has done to us and embrace it.

KingMachiavelli 5y ago

People say that crash reports & telemetry are useful for developers. But I imagine that they also create a lot of work for developers they would not otherwise have. If a user cannot be bothered to open a ticket themselves or at least opt-in to telemetry to demonstrate the issue, then is it really an issue that developer's should fix? If a app crashes in the woods and no one bother's to report it then is it a bug? (Joking partly). For commercial apps the dynamic is a bit different since customer's can & do expect things to be fixed without any action on their part.

crazygringo 5y ago
A lot of bugs are hard to reproduce, occur only on certain OS's, etc. In these cases, filing a ticket is often pretty useless. What's needed are widespread stats to determine severity, frequency, correlations, etc. In fact, I'd say the Venn diagram of bugs that can be meaningfully reported in a ticket, versus those best detected through crash reports, is pretty small. So you need both. Why do you think developers shouldn't fix crashes? Shouldn't developers themselves decide what they want to fix?

fouric 5y ago

I do not support this idea. The differences between the things they all group together under one umbrella is wild - ads, usage reporting, automatic updates, and crash reporting are all very different things and it's actively harmful to control all of them with a single switch. At the very least, there should be two different switches - "ads" and "everything else". If you don't want telemetry or crash reporting, that's fine - you may not care about helping the developers of an open-source project improve their software and that's your personal choice. Similarly, you may want to manually install security patches, while I want them to be automatically installed so I have one less thing to worry about. There may even be some crazy person that wants ads. I don't, but I'm not going to try to take away their freedom to choose them, which is what this proposal would do - an all-or-nothing switch for non-essential network access. Give me granularity. There's no (user-facing) reason not to.

Seirdy 5y ago
Lots of people in the Free Software community think that programs should exist only to help the user, and should just do exactly what the user tells them to do and nothing else. I am one of those people. Showing ads, making network requests that aren't necessary to carry out the expected functionality, etc. all fall under violations of that principle. Some violations are worse than others, but I treat them the same way. It's on the developers of the software to make these settings granular and off-by-default. If I want to help a developer, I'll go out of my way to do it and flip one of those switches if that's what it takes. Personally, I don't think this goes far enough; I think programs should require explicit consent simply to connect to the network, and most should request permission to connect only to certain domains. But that's just me ;).
- notatoad 5y ago
  >it's on the developers of the software to make these settings granular and off-by-default. why? privacy advocates in these discusssions always jump to this position and assume everybody is going to agree just because they've invoked the magic p-word. telemetry is useful, and most people don't really care enough to change the defaults one way or the other. assuming that "because privacy" is not an argument that will sway me, can you explain why i should default to the less-useful option just for the sake of appeasing the people most likely to change the defaults?

neiman 5y ago

Here, I fixed it for you. "Console DO Track: A proposed unified standard for opting IN for telemetry for TUI/console apps."

chairmanwow1 5y ago

This website strikes me nothing more than an idea that someone seems to be passing off as a movement. I feel like the negative reactions of the devs of the FOSS projects who got PRs from this person aren't that surprising. To me this doesn't seem to add that much value and I would probably bounce it from my project as well.

holtalanm 5y ago

my question here is: are we really concerned about console tools overreaching their telemetry? personally, I am not. I would love to know why others think this is some kind of huge issue, without a bunch of 'what-if' scenarios.

maddyboo 5y ago
I am. The terminal is one of the few places I am not being tracked. It’s also a portal into my most private data and activity, so if there’s one place I don’t want to be tracked, it’s here. I do not long for a future where the terminal ecosystem resembles the state of the greater internet with regards to privacy and tracking. We’ve collectively watched it happen to almost every other segment of technology in the past 20-odd years, so it’s not far fetched to believe it could happen here as well.
- holtalanm 5y ago
  are there documented cases of these cli tools abusing their telemetry? are they entirely used to pinpoint performance issues and bugs within the tools that implement this telemetry tracking? if it is the former, i can see there being cause for concern. if it is the latter, this is just pure fear-mongering.

ConcernedCoder 5y ago

DONT_BE_EVIL=1

jagged-chisel 5y ago

> We will continue to support the opt out mechanism described here: ... You can, and ALSO support this new thing. Supporting one more env var if you already support one for this kind of functionality is easy and low risk.

renewiltord 5y ago
Then fork and maintain the feature, dude. It's open source. Everyone here wants someone else to do the work but they don't want to do any work.

kgwxd 5y ago

I've been wanting this for years. Why does this target console apps only? Everything should respect it. If I have it set, nothing should even nag me about opting in.

fomine3 5y ago

User tracking isn't purpose of telemetry, so the variable name is misleading.

jasonlotito 5y ago

The assumption should be that the user does not want to be tracked. A ENV stating that is pointless. Scripts that would adopt this are already respecting you by having you opt-in to tracking. It does nothing, and promotes opt-out as the preferred way of showing consent, which is decidedly wrong.

unfletch 5y ago

Another approach: http://github.com/rfletcher/cli-privacy http://github.com/rfletcher/cli-privacy Instead of hoping for various software projects to standardize on a single control, aggregate the various controls in one place, and make it easy to set them all at once.

camgunz 5y ago

Good lord. Please stop writing software that contacts servers I didn't ask it to contact and sends information I didn't ask it to send. It's extremely easy.

thingification 5y ago

Time for this again: https://xkcd.com/463/ https://xkcd.com/463/ What's the alternative? http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ for example (outdated but shows the principle): http://www.cs.jhu.edu/~seaborn/plash/html/ http://www.cs.jhu.edu/~seaborn/plash/html/

tsujp 5y ago

Would this have scope to be added to the XDG Desktop spec, at least on POSIX systems? Except of course, changed to opt-in: XDG_TELEMETRY_ON I'd never set it but at least it be an option for some.

sneak 5y ago
Developers who ship spyware are even less likely to switch to an opt-in model than they are to support a unified system that makes it easy to opt-out.

ramtatatam 5y ago

I'm probably amateur but until today I did not know `aws cli` sends telemetry data... It's probably one of those "terms and conditions" that are way too long to read them, so I'm only half pissed because I did not read it. Indeed, sending such data should be opt-in, NOT opt-out From today on I will ensure each and every CLI I use plays fair game. But actually what did I expect, since for Firefox telemetry data is on by default :/

jrochkind1 5y ago

opting out of checking for "updates" in homebrew would probably harm your homebrew use more than most users realize. You won't ever be getting new formulae etc.

kazinator 5y ago

> respect the following environment variable This is under-specified without giving a definition of environment variable. For the purpose of this choice, "environment variable" should have the broadest possible interpretation, referring to any relevant space that supports named configuration parameters: - UNIX or Windows environment variable - U-Boot or other boot loader variable. - Kernel parameter: e.g. ... root=/dev/sdb1 DO_NOT_TRACK=1 ... - URL parameter: https://domain.example/foo/bar&param=24&DO_NOT_TRACK=1&... Basically any configuration variable that is relevant in the specific context. Lower-level system software which executes before there are environment variables should not be off the hook.

jefftk 5y ago
Their proposal is for console apps, and gives the example "export DO_NOT_TRACK=1". They are talking about your first bullet, and not any of the others.

zomglings 5y ago

In Bugout, we have implemented a global do not track environment variable: export BUGGER_OFF=true If you set this variable, any tools collecting usage and crash reports using Bugout will not phone home with those reports. (You can also use BUGGER_OFF=yes, BUGGER_OFF=1, etc.)

dantondwa 5y ago

The reaction of homebrew [1] really makes me dislike the project. They just answered with bullcrap, instead of directly addressing the matter. [1] https://github.com/Homebrew/brew/pull/6745 https://github.com/Homebrew/brew/pull/6745

oytis 5y ago

It is so depressing that we need this thing in the first place. What next, CONFIG_DO_NOT_TRACK so that kernel modules don't send telemetry to hardware vendors? Adtech "ethics" (lack of thereof) has become a huge problem for the community.

lamby 5y ago

"It looks like you are writing a letter^W^W^Wexperiencing a systemic problem. Would you like an individualised solution to that?"

kuba-orlik 5y ago

I think that this approach kind of dissolves the power of the word "consent" > plainly and unambiguously expresses LACK OF CONSENT by a user in GDPR terms, consent can never be assumed. In order to be valid, the consent has to be a result of a conscious, explicit action from the user. Things that are opt-out cannot use "consent" as a legitimizing premise