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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support DO_NOT_TRACK env var in addition to --telemetry-disable #737

Closed
sneak opened this issue Mar 6, 2020 · 12 comments
Closed

Please support DO_NOT_TRACK env var in addition to --telemetry-disable #737

sneak opened this issue Mar 6, 2020 · 12 comments

Comments

@sneak
Copy link

@sneak sneak commented Mar 6, 2020

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

@vndre vndre commented Mar 8, 2020

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

@sneak sneak commented Mar 8, 2020

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

atom/telemetry#33

@Avlyssna
Copy link

@Avlyssna Avlyssna commented Mar 8, 2020

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

@erquhart erquhart commented Mar 8, 2020

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鈥檚 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鈥檛 want to stamp out forward moving conversations, but that really didn鈥檛 feel like one.

Sent with GitHawk

@sneak
Copy link
Author

@sneak sneak commented Mar 8, 2020

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

It鈥檚 inaccurate to claim that I鈥檓 not looking for a real conversation. Please don鈥檛 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鈥攜ou may note that you dismissed it initially without understanding it.

@vndre
Copy link

@vndre vndre commented Mar 9, 2020

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

@erquhart erquhart commented Mar 9, 2020

I鈥檓 not sure we鈥檙e talking about what actually happened - to clarify:

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

Sent with GitHawk

@sneak
Copy link
Author

@sneak sneak commented Mar 9, 2020

A single call was being made at the time of passing the 鈥攖elemetry-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
Copy link

@vndre vndre commented Mar 9, 2020

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

This comment has been minimized.

@erquhart
Copy link
Contributor

@erquhart erquhart commented Mar 9, 2020

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

That 鈥渇orce鈥 is only in place when processing the 鈥攖elemetry-enable and 鈥攖elemetry-disable flags, as we were wanting to capture a user鈥檚 indication that they did not want to be tracked. So it worked like this:

  1. User runs a cli command with 鈥攖elemetry-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 鈥渟pamming鈥 towards @anskydev is also unnecessary and uncalled for.

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

I鈥檒l 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.

@erquhart erquhart closed this as completed Mar 9, 2020
@sneak
Copy link
Author

@sneak sneak commented Mar 9, 2020

Please refrain from commenting on individual contributors in a negative fashion

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

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

No branches or pull requests

4 participants