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

observe DO_NOT_TRACK per consoledonottrack.com #6158

Open
wants to merge 1 commit into
base: master
from

Conversation

@sneak
Copy link

sneak commented Nov 15, 2019

  • disables phone-home for autoupdate if DO_NOT_TRACK env set
  • disables crash reporting if DO_NOT_TRACK env set

Purpose

https://consoledonottrack.com

This allows for a single environment variable that users can set to explicitly opt out of nonessential phone-home (autoupdates, crash reporting).

Testing

I have not tested this but have modeled it after the existing code that short-circuits around these functions and it is a very small change.

* disables phone-home for autoupdate if DO_NOT_TRACK env set
* disables crash reporting if DO_NOT_TRACK env set
@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

just realized this is incomplete and needs to be amended for URAccepted to disable usage reporting too.

@imsodin

This comment has been minimized.

Copy link
Member

imsodin commented Nov 15, 2019

While I am very sympathetic to the purpose (add a common switch for all applications to disable tracking) I am not enthusiastic about adding an "arbitrary" env var to Syncthing. At this point it is just that: There's no adoption (obviously, as it's new), but crucially also no visible support by any minor or major players. I believe by directly opening PRs you are taking the wrong approach. It seems way more likely to succeed by first creating a draft outlining the mechanism, then distributing that among projects. If this were an initiative by freedesktop, a DE or whatever, the situation would be an entirely different one (aka there is a chance of wideish adoption, which I currently don't see).

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Nov 15, 2019

Also, the domain name is peppered everywhere as if this is some SEO trick. Given you are the owner of the idea, I do take this PR as marketing rather than a serious feature. I don't think you should pollute opensource projects in order to market your idea.

Also, this is such an obscure feature, some magic env var set can completely screw up operational aspects of syncthing. In theory what you did is not enough, as we should disable relays, discovery etc, as they are a form of phone home from which we track stats, etc, yet without them, the software is completely non-functional.

Now I become a privacy advocate, set that env var ahead of time because I like the idea, 3 months later download syncthing, it is completely broken because of your env var, and then go complain on our forum leading to increased nonsensical support.

@calmh

This comment has been minimized.

Copy link
Member

calmh commented Nov 15, 2019

I think the page at the linked domain is the outline. What Audrius says is true though. This disables the upgrade check, which is one of the things we do not mine for statistics or keep client data on, as opposed to the usage reporting and discovery, both of which are a form of tracking.

I think leave this for consideration for the moment. Once there is a standard that is more clarified in terms of expectations I'll be happy to support it.

And by "expectations" I mean "how broken should the user expect the software to be when setting this variable". If it's supposed to disable all non-LAN communication then Syncthing is essentially dead in the water for the purposes of most users. Using Syncthing in such a scenario is possible and people do it, but it requires care and aforethought beyond setting an env var.

@calmh

This comment has been minimized.

Copy link
Member

calmh commented Nov 15, 2019

Looking at the other examples from the site I get the feeling this is mostly about telemetry. So in our case that would mean no usage reporting and maybe no upgrade checks, but keeping discovery enabled.

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Nov 15, 2019

We don't collect telemetry out of the box anyway, the user is forced to choose where the default is "do not track", so I question value of an env var that supposedly does the same.

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

Yeah, discovery and relay are clearly essential to functionality for most users, and are unavoidable in terms of IP address transmission. Usage reporting, crash reporting, and upgrade checks are nonessential to the functioning of the software.

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 15, 2019

As for SEO - I'm not repeating the domain name for SEO, simply for awareness - I want as many maintainers and users to be aware of this idea as possible, so that I don't have to maintain vigilance about the full list of env vars and /etc/hosts blocks I need to keep software from unnecessarily phoning-home against my wishes. We already know "stdout is for output, stderr is for errors", we already know $HOME is the home directory... I'd like DO_NOT_TRACK to be the default variable that new software is written against for disabling tracking, so that we can all agree on a single, easy-to-set flag. Getting a few projects that are currently spying on users by default to respect it, as well as raising awareness among authors and users, would set the tone for future software that wishes to track while respecting user consent, just like they use $HOME (and sometimes $PORT and $DEBUG or $TRACE) as widespread convention today.

Marketing generally refers to commercial endeavors; I am not selling a thing - I just want an easy way to tell all of my software at once that I would like to explicitly opt out of all nonessential tracking. Based on the messages of support I have received, it seems others feel the same way. I would like to raise awareness of this issue and garner widespread support; if authors insist on collecting tracking information, we as users should be able to insist on a standard method of communicating our consent about such things.

@Catfriend1

This comment has been minimized.

Copy link

Catfriend1 commented Nov 16, 2019

gatsbyjs/gatsby#19528 (comment)

In this comment, I read that nobody else has implemented the env var yet... You could probably post a batch script to GitHub and invite other people to collect existing telemetry-disablers with you there. In the end, just run the script and telemetry is silenced for Syncthing and others. Syncthing asks users if okay with sending data etc. so a batch script is in my eyes not too much being asked if you want to have some special cocktail of disabling features individually.

@sneak

This comment has been minimized.

Copy link
Author

sneak commented Nov 17, 2019

Syncthing does not ask users if they consent to phone-home for updates or crash reporting.

Nobody wants “some special cocktail” - just nonessential tracking able to be disabled with a lever that is labeled consistently across applications.

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