Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

respect DO_NOT_TRACK env var per consoledonottrack.com #6745

Closed
wants to merge 1 commit into from
Closed

respect DO_NOT_TRACK env var per consoledonottrack.com #6745

wants to merge 1 commit into from

Conversation

@sneak
Copy link

@sneak sneak commented Nov 15, 2019

https://consoledonottrack.com

This adds a check for the environment variable DO_NOT_TRACK, a new proposed standard for user opt out of tracking and telemetry in command-line tools.

@MikeMcQuaid
Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Nov 15, 2019

We would rather use our own variable for now (at least until this is much more widely adopted).

@sneak
Copy link
Author

@sneak sneak commented Nov 15, 2019

Nothing about supporting this new standard prevents you from continuing to use your own.

@coderobe
Copy link

@coderobe coderobe commented Nov 15, 2019

If projects don't adopt it unless it becomes widely adopted, how is it supposed to gain wide adoption?
That argument is a self-fulfilling prophecy..

@grxnola

This comment has been minimized.

@spir1donov

This comment has been hidden.

@iMichka
Copy link
Member

@iMichka iMichka commented Nov 15, 2019

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.

I have also the same opinion as syncthing/syncthing#6158 (comment),
this looks more like a marketing move from yourself than something the community really needs/wants.

I also take the opportunity to remember to all our users that we have been really transparent about our analytics strategy: https://docs.brew.sh/Analytics.

@grxnola if you think there is any GPDR violation here, I would like you to give us the exact articles from the regulation which you think we violate. Please open a new issue for this (to not clutter this discussion). We are open to learn and improve what needs to be improved. But I do not think we are doing anything wrong right now, and already have reviewed this topic internally.

Also, if we really need a more formal decision on this, we can involve the Homebrew Technical Steering committee (https://docs.brew.sh/Homebrew-Governance).

I am personally not in favor of adding this env variable.

@coderobe
Copy link

@coderobe coderobe commented Nov 15, 2019

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

Most other package managers do not send analytics by default (or even have the capability of doing so at all) - especially distribution package managers. I'm from the Arch Linux team and we e.g. do not even have rough info on the amount of installed systems, because there is no official data collection at all. Brew and other community-effort or domain-specific package managers are the outliers in that methodology i think.

I for one would really enjoy seeing analytics collectors like brew make this change, to allow for a more standardized and unified way to opt out of data collection. It is a change that will require adoption, and i think getting it introduced into brew & co is a great opportunity to get wider adoption in software like this.
The old methods of opting out are still respected, after all, so there is no compatibility to worry about.

@devlinzed
Copy link

@devlinzed devlinzed commented Nov 15, 2019

We shouldn't accept a future where spyware is the norm and rely on this environment variable. We know how that turned out with HTTP Do Not Track. As long as spyware is bundled with Homebrew, Homebrew shouldn't be used or recommended or normalized. The solution is for Homebrew to remove its spyware by having explicitly opt-in telemetry only.

@MikeMcQuaid
Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Nov 15, 2019

Nothing about supporting this new standard prevents you from continuing to use your own.

@sneak None of the PRs you have opened have been merged yet. As-is: this is not a "standard", it is a webpage you have made with some links to PRs.

If projects don't adopt it unless it becomes widely adopted, how is it supposed to gain wide adoption?

Currently it has no adoption. It's not on Homebrew to change that.

especially as I'm convinced there's already a GDPR violation in the way Homebrew's analytics are opt-out by default...

Thanks for implying legal threats against volunteers who spend their free time making software you use for free!

I'm from the Arch Linux team and we e.g. do not even have rough info on the amount of installed systems, because there is no official data collection at all.

Run your package manager how you want/need and we'll do the same.

As long as spyware is bundled with Homebrew, Homebrew shouldn't be used or recommended or normalized. The solution is for Homebrew to remove its spyware by having explicitly opt-in telemetry only.

No, you've said the solution: you can stop using or recommending Homebrew.


Everyone who comes to this thread should take time to (re)read https://docs.brew.sh/Analytics and note that we tell people about our analytics and direct them to documentation which describes opt-out before we ever send anything (on initial installation or on brew update if you update from a version that doesn't have analytics).

@4n3w
Copy link

@4n3w 4n3w commented Nov 15, 2019

We would rather use our own variable for now (at least until this is much more widely adopted).

Adopting this standard is zero-cost, I'm confused why this was closed.

@iangreenleaf
Copy link

@iangreenleaf iangreenleaf commented Nov 15, 2019

You're denigrating this as a marketing effort and something in need of standardization, but if you were going to pick a generic env var to control tracking behavior, what would be a better choice than DO_NOT_TRACK?

@MikeMcQuaid
Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Nov 15, 2019

Adopting this standard is zero-cost, I'm confused why this was closed.

@4n3w a few things:

  • it requires code changes which need to be maintained
  • as-is this PR won't work at all (evidently it was not tested)

and something in need of standardization

No-one from Homebrew has made that claim.

This conversation is not a good use of anyone's time at this point. When more projects have adopted this: we will reconsider it.

@Homebrew Homebrew locked as too heated and limited conversation to collaborators Nov 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants