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 #19528

Closed
wants to merge 3 commits into from

Conversation

@sneak
Copy link

sneak commented Nov 15, 2019

Description

https://consoledonottrack.com

This introduces a check for the DO_NOT_TRACK environment variable standard for users to express clear lack of consent to telemetry tracking.

@sneak sneak requested a review from gatsbyjs/core as a code owner Nov 15, 2019
@freiksenet

This comment has been minimized.

Copy link
Contributor

freiksenet commented Nov 15, 2019

Hi!

Thank you for your contribution!

We are happy to add this, however I have couple of questions/comments first:

  1. Are there any other projects that have adopted this?
  2. Could you link to a standard description in a comment above the condition?

Thank you!

@freiksenet

This comment has been minimized.

Copy link
Contributor

freiksenet commented Nov 15, 2019

non-essential-to-functionality requests of any kind to the creator of the software or other cloud or tracking services

This condition is highly ambiguous, we call to unpkg.com to format stack traces in error messages better - is that an non-essential-to-functionality request?

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

It sounds like formatting stack traces into error messages is functionality, and isn’t a phone-home for purposes of tracking - it doesn’t seem ambiguous what “to track” means in this context, at least to me.

Also, considering that unpkg and gatsby are different entities, and unpkg isn’t providing a tracking service to gatsby, it is pretty plainly not an instance of tracking (either first or third party) but just network-based functionality.

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

I will update the PR as requested. Nobody else has adopted it yet because I just had the idea and made the site yesterday; the PRs are all pending.

@blainekasten

This comment has been minimized.

Copy link
Contributor

blainekasten commented Nov 15, 2019

@sneak I appreciate what you are doing here. And I see that it's having some difficulty taking off (looking at the other libraries PRs). While I believe we are happy to take this I have an idea that might be more beneficial for you to scale this.

Right now to scale this, you need to get this integrated into enough libraries that it becomes common enough for people to carry the torch forward. Submitting PRs to libraries and landing it seems like it might be hard.

Another option instead of standardizing on a single env var is to make a script that users can download and it will set global envs for all the libraries.

So an idea is basically, on your website you have some curl script which downloads and executes something that just does

export GATSBY_TELEMETRY_DISABLED=1
export HOMEBREW_NO_ANALYTICS=1
export STNOUPGRADE=1

The benefits that might occur here is that you will have a central repository and takes zero library buy in from library authors.

Feel free to ignore this idea, just thought I would throw it out there!

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

I appreciate the suggestion, but then I need to know a full list of packages that have tracking/spyware/telemetry/analytics/usage reporting/whatever and continuously update the package (and users have to continuously update their list of exports in .profile or whatever to remain safe from being spied on). If we get momentum behind a single, standardized variable, users will be safer without continuous vigilance (provided that maintainers respect the variable and don't balkanize), which is the whole point here.

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 16, 2019

@freiksenet

Responses:

Are there any other projects that have adopted this?

Not yet, though syncthing seems open to it and homebrew says they'll consider it once some other projects do. The PR to syncthing still needs another couple changes that I haven't had time today to make - this whole idea was cooked up yesterday (and seems to have garnered a lot of support).

Could you link to a standard description in a comment above the condition?

I updated the PR, will update again with any linting fixes as required by CI.

@blainekasten

This comment has been minimized.

Copy link
Contributor

blainekasten commented Nov 18, 2019

@sneak I absolutely understand. I'm just spit-balling here. It seems like the path of least resistance here is to not require library authors to respect some specific key, even if it is a good idea to do so.

The way I see it, users who care about this are going to be more passionate about this than library authors. So if you have a central repository, everyone who is a "supporter" will be a contributor potentially. They'll submit PRs to add some libraries specific env var to the master list, which then everyone gets.

You can then have your script compare itself against the upstream master to suggest users to re-run it for updates. I'm merely suggesting these things because I've noticed the other PRs you opened were closed and dismissed. Homebrew/brew#6745, syncthing/syncthing#6158

Again, I commend this idea and just want to see it work out for you!

@muescha

This comment has been minimized.

Copy link
Contributor

muescha commented Nov 18, 2019

as an beginning you can start just with a readme or Better an json file which you can post on your website.

Like an awesome list of don't track environment vars or other commands (Google cloud cli) or settings for opt out and a link to the settings page or info page or something.

As next step some one can write a utility which consume the json.
Maybe also some detectors which analyze the package.json and recommend the settings for known npm dependencies.

If a library implemented the option in source the get a big green checkmark on website

As I read the comments in other repos for your PR there is an demand for your idea.

@muescha muescha mentioned this pull request Nov 18, 2019
@muescha

This comment has been minimized.

Copy link
Contributor

muescha commented Nov 18, 2019

@sneak @blainekasten

I opened an issue about the idea of an script or list at sneak/consoledonottrack.com#8 - lets continue the discussion there

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 19, 2019

Let's please keep this discussion on track: this issue is about a specific proposed change to Gatsby, supported by code, to support DO_NOT_TRACK.

@pieh

This comment has been minimized.

Copy link
Contributor

pieh commented Nov 19, 2019

Hey @sneak!

As mentioned before, we would be interested in supporting this flag (in addition to our own) if there was some adoption by major projects already. gatsby is not interested in being first one (or one of first ones) to support this env var: this would make us de facto advocate for this standard, and it would be somewhat in our interest to promote it, but in practice we don't have stake in this.

For now I will close the PR, but as mentioned before - happy to re-open when the standard gets some adoption.

@pieh pieh closed this Nov 19, 2019
@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 19, 2019

@pieh what does any other software's actions or lack thereof have to do with Gatsby supporting this flag?

It doesn't matter who's first or who's last. If you think it's a good idea, then do it. This is about making it easier for users.

@pieh

This comment has been minimized.

Copy link
Contributor

pieh commented Nov 19, 2019

@pieh what does any other software's actions or lack thereof have to do with Gatsby supporting this flag?

Because in the vacuum, we would add support for non-GATSBY_-prefixed env var that people might already use for something else (likely - no, but possible). Env vars that we do handle have either GATSBY_ prefix or are already used in multiple different projects - like FORCE_COLOR for terminal output

@m-allanson

This comment has been minimized.

Copy link
Member

m-allanson commented Dec 4, 2019

Here is a project that describes how to opt out of telemetry for various tools: https://github.com/beatcracker/toptout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.