Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign uprespect DO_NOT_TRACK env var per consoledonottrack.com #19528
Conversation
This comment has been minimized.
This comment has been minimized.
Hi! Thank you for your contribution! We are happy to add this, however I have couple of questions/comments first:
Thank you! |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
@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
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! |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
Responses:
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).
I updated the PR, will update again with any linting fixes as required by CI. |
This comment has been minimized.
This comment has been minimized.
@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! |
This comment has been minimized.
This comment has been minimized.
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. 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. |
This comment has been minimized.
This comment has been minimized.
I opened an issue about the idea of an script or list at sneak/consoledonottrack.com#8 - lets continue the discussion there |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. For now I will close the PR, but as mentioned before - happy to re-open when the standard gets some adoption. |
This comment has been minimized.
This comment has been minimized.
@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. |
This comment has been minimized.
This comment has been minimized.
Because in the vacuum, we would add support for non- |
This comment has been minimized.
This comment has been minimized.
Here is a project that describes how to opt out of telemetry for various tools: https://github.com/beatcracker/toptout. |
sneak commentedNov 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.