This has been denied by big players such as .NET and Homebrew. This is a classic case of https://xkcd.com/927/
Console Do Not Track – Proposal for a standard environment variable
11–20 of 352 posts
Re: Console Do Not Track – Proposal for a standard environment variable
#12This has been denied by big players such as .NET and Homebrew. This is a classic case of https://xkcd.com/927/
What are the competing standards?
Re: Console Do Not Track – Proposal for a standard environment variable
#13This is from 2019, should be flagged as such.
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-855087...
Re: Console Do Not Track – Proposal for a standard environment variable
#14i 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...
Re: Console Do Not Track – Proposal for a standard environment variable
#15I 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?
This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...
Re: Console Do Not Track – Proposal for a standard environment variable
#16"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.
Re: Console Do Not Track – Proposal for a standard environment variable
#17I 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?
This comment from a Homebrew maintainer should answer your question: https://github.com/Homebrew/brew/pull/6745#issuecomment-5543...
Re: Console Do Not Track – Proposal for a standard environment variable
#18This is negative consent. I can't fathom why we are supposed to be ok with that. The variable should be named DO_TRACK.
Indeed. And don’t such tools require GDPR consent to allow tracking or processing PII?
GDPR specifies what are valid reasons for collecting data, but as far as I know it does not require opt-in.
Re: Console Do Not Track – Proposal for a standard environment variable
#19This is negative consent. I can't fathom why we are supposed to be ok with that. The variable should be named DO_TRACK.
Indeed. And don’t such tools require GDPR consent to allow tracking or processing PII?
> And don’t such tools require GDPR consent to allow tracking or processing PII?
They actually do, yes. I can see an auto-update "phone home" as justified interest to be able to quickly revoke insecure software, but usage analytics are clearly opt-in only.
Re: Console Do Not Track – Proposal for a standard environment variable
#20I 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?
These PRs are like bad dating app messages - they get threatening so quickly when the author is rejected.