respect DO_NOT_TRACK env var per consoledonottrack.com

[sneak]

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.

[freiksenet]

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]

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]

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]

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]

@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]

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]

@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]

@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]

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]

@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]

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]

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.

[sneak]

@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]

@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]

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