observe DO_NOT_TRACK per consoledonottrack.com

[sneak]

• 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.

[sneak]

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

[imsodin]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[st-review]

🤖 beep boop

I'm going to close this pull request as it has been idle for more than 90 days.

This is not a rejection, merely a removal from the list of active pull requests that is periodically reviewed by humans. The pull request can be reopened when there is new activity, and merged once any remaining issues are resolved.

[shabbyrobe]

Should this be closed? I don't think the issue is necessarily resolved. It's very disappointing to see so many larger projects that have been asked to consider this effectively say "sorry, until all the other larger projects do this, we won't". If just a couple of projects saw the merit, accepted the PR, then observed how it goes with other projects, it can be removed later if it doesn't get traction.

[sneak]

Netdata has adopted this setting.

netdata/netdata#7846

[calmh]

The bot comment above explains why this is closed - it's not implemented correctly, and hasn't been touched in 90 days.