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

Conversation

@sneak
Copy link

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

This comment has been minimized.

Copy link
Member

MikeMcQuaid commented Nov 15, 2019

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

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

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

@coderobe

This comment has been minimized.

Copy link

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.

Copy link

grxnola commented Nov 15, 2019

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

@spir1donov

This comment was marked as outdated.

Copy link

spir1donov commented Nov 15, 2019

@grxnola, did you mean opt-in by default?

@iMichka

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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.
Projects
None yet
9 participants
You can’t perform that action at this time.