Skip to content

respect DO_NOT_TRACK env var per consoledonottrack.com #19528

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

Closed
wants to merge 3 commits into from
Closed

respect DO_NOT_TRACK env var per consoledonottrack.com #19528

wants to merge 3 commits into from

Conversation

sneak
Copy link

@sneak 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 a team as a code owner November 15, 2019 02:48
@freiksenet
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
Copy link
Contributor

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
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
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
Copy link
Contributor

@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
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
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
Copy link
Contributor

@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
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
Copy link
Contributor

muescha commented Nov 18, 2019

@sneak @blainekasten

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

@sneak
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
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
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
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
Copy link
Contributor

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

@sneak
Copy link
Author

sneak commented Feb 1, 2020

@pieh netdata has adopted this now. Would you please reopen?

@bogdansoare
Copy link

any news on this?

@Bazai
Copy link

Bazai commented Jul 7, 2021

@pieh ?

@ibz
Copy link

ibz commented Feb 13, 2023

"not interested in being first one" when it comes to user privacy?

@TylerBarnes
Copy link
Contributor

@ibz that's quite a stretch. There is already a flag to turn off tracking if you read the thread and look at the PR changes.

@ibz
Copy link

ibz commented Feb 13, 2023

@TylerBarnes It's not. I did read the whole thread. The reply was clear: "this would make us de facto advocate for this standard". Basically gatsby chooses to not favor a proposed standard that would improve user privacy even though all they had to do was to accept a PR. Bad move.

@muescha
Copy link
Contributor

muescha commented Feb 13, 2023

The author of the proposed standard deleted (t)his repo at GitHub 🤔

So it is not active anymore

@sneak
Copy link
Author

sneak commented Feb 14, 2023

That's not accurate. Only the jekyll site sources have been removed from GitHub as I no longer use GitHub for source code as Microsoft is an unethical company.

https://consoledonottrack.com

@ibz
Copy link

ibz commented Feb 14, 2023

Not only it is inaccurate, but it is irrelevant.

Gatsby rejected the PR only 4 days after it was opened, using "not interested in being first one" as a reason. So user privacy is clearly very low on their priority list. All they had to do was approve a PR that was already there - absolutely zero resources / time investment required on their side.

Very bad PR for Gatsby. Yes, pun intended. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants