Please support DO_NOT_TRACK env var in addition to `--telemetry-disable`

[sneak]

Per https://consoledonottrack.com (hosted on Netlify, incidentially 😉):

Gatsby has GATSBY_TELEMETRY_DISABLED. Homebrew has HOMEBREW_NO_ANALYTICS. Syncthing has STNOUPGRADE, a config file setting for disabling crash reporting, and a GUI prompt for usage reporting. Google Cloud SDK CLI tools has gcloud config set disable_usage_reporting true. .NET Core has DOTNET_CLI_TELEMETRY_OPTOUT. The AWS Serverless Application Model CLI has SAM_CLI_TELEMETRY=0. The Microsoft Azure CLI has AZURE_CORE_COLLECT_TELEMETRY=0. You get the idea.

I currently have to maintain an extra line in my build scripts to disable telemetry for Netlify's CLI. Could you please support this standard variable to disable telemetry?

There is precedent: NETLIFY_SITE_ID is used instead of an arg to netlify deploy, and NETLIFY_AUTH_TOKEN is used instead of netlify init. Presumably these are for ease of CI; it would be lovely if you could apply the same approach to disabling the consent-presuming spying functionality.

[vndre]

I'm commenting on this issue since the original one and the PR created has been already locked (why? I thought formal discussions were positive for both sides..., it is not like they are fixing something "shady" they did without making too much noise about it right?)

This issue goes beyond the "it is legal because you blindly agreed so", the issue is about Netlify destroying ALL of the trust built with their costumers (at least they just made me never want to use Netlify again).

The creator of this PR, claims a line of code was previously added without an issue or an approved PR (and using something like Github and not having a registry of this action makes you wonder why), and the line of code that would still be there if it weren't because @sneak?

track('user_telemetryDisabled', { force: true })

Yep, there were FORCING telemetry EVEN if the customer explicity disabled that "option". I've only seen this nasty way of spying on the levels of Microsoft.

Honestly I don't know if this legally goes against GDPR but one of the conditions is: "The data subject shall have the right to withdraw his or her consent at any time. 2The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. 3Prior to giving consent, the data subject shall be informed thereof. 4It shall be as easy to withdraw as to give consent."

I know the PR has already been merged but that was really serious and close: The GDPR was violated due to "it is not easy to withdraw from the consent" since setting the option "TelemetryDisable" was always override by their hardcoded config and thus not letting the customer truly withdraw their consent.

I'm noy against Netlify, actually it seems like a really cool service, but things like this makes me wonder why not been transparent since the beginning? why the need to steal information from the user when is so easy to ask for it first?

[sneak]

GitHub's Atom text editor also does this, and AFAIK they did it before they became Microsoft:

atom/telemetry#33

[Avlyssna]

As was the case for other issues on this topic, this will likely be resolved and locked in a swift form of damage control. Although I have no stake in Netlify's interests, the situation that @sneak has stumbled upon is rather odd and concerning - especially considering the issues @anskydev raised. What I believe is more concerning would be the developer's blanket response initially in #739: blindly dismissing the issue and closing it.

The cli has to connect to Netlify to work, hence the call to cli.netlify.com. If you disable telemetry, we don’t use telemetry.

Conversations of privacy are necessary to maintain the trust of your users. Although I don't entirely agree that a rant about ill-intentions from developers was a great way to start off #739, Netlify is casting themselves in a shady light with how they've handled the issue so far.

[erquhart]

Yeah locking was a tough call tbh. That issue was super incendiary, and gave zero benefit of the doubt, hence my initial dismissal. The user that opened it has opened similar issues on repos elsewhere and it’s clear they are never looking for a real conversation. I decided to lock the issue because it had gotten quite a bit off topic, and had been resolved.

I definitely don’t want to stamp out forward moving conversations, but that really didn’t feel like one.

_{Sent with GitHawk}

[sneak]

The fact that developing and distributing software that is violating user consent is unethical is not a rant, nor is it individual opinion.

It’s inaccurate to claim that I’m not looking for a real conversation. Please don’t make authoritative claims about my desires until and unless you know them for a fact.

I have opened them on other repos because other companies also engage in this sort of unethical behavior, and it needs to stop. Your company stopped as a result, for example, and only because I made a loud noise about it—you may note that you dismissed it initially without understanding it.

[vndre]

The saddest thing is that you can track that this was set since one of the first releases: v2.0.0-beta.3 released 9 Sep 2018... How many data from how many users is that? Your policy says (this is a rephrase): "we may share the data with third parties" so I assume you do so. Now, I'm not saying this is one of the reasons but with all the lack of communication and this secrecy it just makes me wonder if you sell that data to advertising companies, you not only track your customers data, but also the data of the users that connect to the products hosted in your servers.

Handling all that data is a delicated topic, and by the way you have handled it until now (or rather, haven't) it seems you don't care about the privacy of your customers...

If it weren't for @sneak efforts everything would still be the same, so thanks for that.

"And I would have gotten away with it too, if it weren't for you meddling kids".

[erquhart]

I’m not sure we’re talking about what actually happened - to clarify:

• A single call was being made at the time of passing the —telemetry-disable flag.
• No further telemetry calls were ever made again unless —telemetry-enable is called - that is to say, disabling telemetry was never broken.
• This PR removes the call in question.

_{Sent with GitHawk}

[sneak]

A single call was being made at the time of passing the —telemetry-disable flag.

Yes, that's that whole issue. Doing telemetry to say the user doesn't want telemetry, when you, at the time of the telemetry call, know the user doesn't want telemetry, but you do it anyway: force: true. It's fixed now, as you note, but it speaks to the attitudes of the company and implementors with regards to ethical behavior.

This entire discussion is off topic for #737 , though, so let's end that part of it.

This GitHub issue is about supporting an environment variable that a user can set so they don't have to set some config file json (somewhat difficult to do via a script) or know in advance about some flag buried in the documentation. It's been adopted by the netdata team and other software packages and developers have expressed interest. There is precedent in the Netlify CLI for specifying things via env vars, for example for use in CI.

How about it? Shall I send a PR?

[vndre]

Yes, that's what happened regarding this situation in the last couple days, and I appreciate the quick and fast response to this issue. What I am discussing is what this issue showed us about the code.

More specific, I'm concerned about why that code was there in the first place, now you have worked on this project and you know more about the logic behind all, and maybe you can clarify the purpose of it:

src/utils/telemetry/index.js

function track(eventName, payload) {
  const properties = payload || {}
  ...
  ...
  const TELEMETRY_DISABLED = globalConfig.get('telemetryDisabled')
  if (TELEMETRY_DISABLED && !properties.force) {
    if (DEBUG) {
      console.log('Abort .track call TELEMETRY_DISABLED')
    }
    return Promise.resolve()
  }

Calls to that function from src/hooks/init.js:

    track('user_telemetryDisabled', {
      force: true
    })

In the track function you first get the flag telemetryDisabled from the user but the if condition also checks for the second parameter, in this case { force: true } makes if (... !properties.force) false and hence the function skipping the resolve of the promise and then calling send() function with some user data (userID and cliID only I guess?).

If that is what was actually happen that was illegal and a way to "fool" your customers into thinking that they have the control of their privacy (even if you argue the data you still sent was relative "harmless" the point is customer data is customer data), and with that broken trust I can only wonder where else in the code you could take advantage of something like this.

But if I'm confused and stating false things maybe you can explain us what was the intention with all of that and maybe you could update the readme with specific details about what you do with that user data so future anskydevs don't doubt about Netlify intentions with our data, if it is not much of a burden obviously, and thanks for the time.

-- sorry for the off-topicness, but I don't know where else go with my concerns, anyways I will not spam anymore, thanks for the patience ---

[sneak]

Per 5f1cf55 , @DavidWells is the one who wrote that call, and was so proud of it he put on his CV: https://davidwells.io/resume/

@anskydev, perhaps you could ask him directly/privately and please stop spamming this thread (his contact info is available in the link above). The issue you are describing is documented in #739 and was fixed in #740 by @erquhart.

[erquhart]

@anskydev I definitely understand the confusion here! Happy to explain:

That “force” is only in place when processing the —telemetry-enable and —telemetry-disable flags, as we were wanting to capture a user’s indication that they did not want to be tracked. So it worked like this:

1. User runs a cli command with —telemetry-disable flag
2. CLI sees the flag, and sends one telemetry request to note that it was disabled
3. CLI updates the global config for persistent disabled telemetry
4. No further telemetry requests occur in current or future sessions

Hope that helps.

@sneak I hid your last comment as it is not in agreement with our code of conduct. Please refrain from commenting on individual contributors in a negative fashion, or redirecting community members to contact individual contributors privately. Your accusation of “spamming” towards @anskydev is also unnecessary and uncalled for.

To your original point for this issue, thanks for your interest, but this isn’t an approach we plan to adopt.

I’ll elaborate on this decision for anyone that sees this in the future:

• This is a standard created by the user that opened this issue
• There is no sign of general adoption of this standard by other projects
• There is no sign of general adoption of this standard by the general development community

Starting a true standard requires the hard work of conversation and earning buy-in from the community that the standard applies to.

[sneak]

Please refrain from commenting on individual contributors in a negative fashion

Could you please let me know where I did that? I'm confused.