4 ms·

The idea would include an opt-out. It would probably be easier to use the opt-out rather than maintaining a fork.

by rocqua 4y ago

jonhohle 4y ago
But the feature should be opt-in to begin with. Opt-out is an anti/dark-pattern that should rightfully be derided.
- alkonaut 4y ago
  Opt-in greatly reduces the statistical quality of the data. That said, there are many forms of Opt-out. It's one thing to show a checkbox in the setup of a desktop applicatoin saying "send anonymous usage data" and have the checkbox pre-checked. That's a form of opt out, but it's not hidden. It's quite different to have a system enabled which is only possible to switch off by googling a solution or digging in a settings menu. That's also opt-out, but it's a much darker pattern than the pre-checked checkbox. Obviously, a command line tool doesn't have the luxury of an interactive setup, so the same patterns don't apply, but whether or not something is "opt out" or "opt in" isn't the entire story. I find the "default" to be the important thing. Developers need "the default" to be enabled to get reasonable coverage. That doesn't mean it needs to be "secretly" enabled.
  - throwntoday 4y ago
    This doesn't change what the parent comment said. Opt-out is inherently a dark pattern. The hope is that the person installing the software doesn't actually read and uncheck the box. It's no different to "install bing toolbar" for example being pre-checked and snuck in to directx.
    - alkonaut 4y ago
      > The hope is that the person installing the software doesn't actually read and uncheck the box Yes. Because you have the "don't care" group being the important group. The users are split into a small group being positive (The would-opt-ins) and a small group being negative (the people arguing it must be opt in) and a large group who don't care. The central "don't care" group is so large that the data is almost useless without them - i.e. you could just as well not have the system at all if you were going to do a full opt-in. So the unchecked box alternative really isn't an alternative.
      - Lio 4y ago
        You've missed out a group there, it's: * Would-opt-ins * Would-opt-outs * Don't-cares * Did-not-know-that-google-are-going-to-run-telemetrys By making it opt-out Google will be conveniently hoovering up the people that would say objects if they knew along with the don't cares.
        alkonaut 4y ago
        Yes my 3-group would be the case for the checkbox-during-installer-of-desktop-app.
  - layer8 4y ago
    The checkbox being pre-checked is still not legal in some countries, exactly because it favors the non privacy protecting option.
    - alkonaut 4y ago
      > The checkbox being pre-checked is still not legal in some countries exactly because it favors the non privacy protecting option I think you are confusing this with systems that gather any PII, and regulations such as the GDPR and similar. This is about collecting data without any PII so any privacy regulation wouldn't apply here.
      - layer8 4y ago
        If the telemetry data is associated with the IP or contains anything that can be used to identify or track the particular Go installation (similar to a browser fingerprint), then it can be considered PII.
        alkonaut 4y ago
        Of course. But then it's not "anonymous usage statistics" at all is it?
        layer8 4y ago
        I don’t know how they can collect useful statistics when they cannot distinguish between 1000 invocations by the same user/environment vs. one invocation by 1000 different users/environments. And when they can distinguish, then that tracking is prone to fall under personal data processing.
        alkonaut 4y ago
        Most off the shelf systems work with random pseudonyms: You generate a unique random number and store it only on the end user's system. Then you tag each data value with the random id one. These random identifiers do not count as PII so long as it is not possible to tie them to a real identity. So while you are of course required to follow data processing regulations, pseudonymous usage statistics with random identifiers is not against any regulation I know about at least. The lifespan of the pseudonym can be as long or short as you want e.g. last one session, one week, one version etc. But even when completely persistent, they will not constitute PII.
  - Lio 4y ago
    > Obviously, a command line tool doesn't have the luxury of an interactive setup, Why would the command line tool not have the option of an interactive setup? Many command line tools ask you to say yes/no to things the first time they are run. Even if you want to reconfigure a tool it shouldn't be difficult to retrigger a decision tree.
    - alkonaut 4y ago
      > Why would the command line tool not have the option of an interactive setup? Typically because (at least if it's already shipped) there are hard expectations about what it will do. E.g. that it shouldn't block waiting for input. That might screw headless/CI uses. A shipped product probably also doesn't have the luxury of using a /noninteractive or /noTelemetry or requiring an env car or similar to block it, because the CI scripts are already written. You can have it ask the user (block waiting for input) if its given a NEW command line option. But you can't do it in the absence of that option. That's why, for a shipped product, it's so much easier to make it opt out. The alternative would be to make it opt in via command line switch or env var - which would obviously be so rare that there is no point in doing it at all.
      - jonhohle 4y ago
        How many CI environment are (or at least should be) connected to the internet to begin with? That almost certainly eliminates the possibility of reproducible builds but also opens all kinds of security issues. (I know sandboxes builds are not common place, but they really should be.)
        alkonaut 4y ago
        > How many CI environment are (or at least should be) connected to the internet to begin with No idea. If I had to make a guess I'd say 99%?
  - jonhohle 4y ago
    Xcode command line tools require a one-time license agreement. FreeBSD ports will open an ncurses based configuration dialog if there are new options. Plenty of Java tools will prompt for JAVA_HOME if they can’t figure out where it is and the JVM forces providing arguments for enabling some license restricted features. Telemetry from a private system should always be opt-in. I find it concerning that developers think they have some default right to data on systems they don’t own without explicitly getting permission. It may be technically possible, it may be statistically necessary, but it’s morally bankrupt and erodes the peer relationship that should exist in open source software.
    - alkonaut 4y ago
      > Telemetry from a private system should always be opt-in. I have to disagree. I think it should be visibly communicated (not snuck in under the radar) but such cases default on should be acceptable so long as it is clearly communicated. Command line systems ARE inherently more difficult than the installer checkbox I'm used to (but by no means impossible to work with). > Xcode command line tools require a one-time license agreement > plenty of Java tools will prompt for JAVA_HOME if they can’t figure out where it is This is easy enough if done from the start, but it's hard to do without breaking existing users's scripts if you have the requirement that "We don't stop and ask for permission in v2.0 if we didn't in v1.0 given the same arguments and environment, as that will break people's builds". And as a user of a command line tool I have to say that requirement seems much more important... This is why it's a good idea to have a /noninteractive switch for command line tools. You can state from v1.0 that without it, it might block at any point in any later version , so any script that doesn't use it made a mistake. > developers think they have some default right to data on systems they don’t own without explicitly getting permission What is explicitly asking here? Is the checked state of a checkbox part of whether it's explicit? > it’s morally bankrupt and erodes the peer relationship that should exist in open source software. Yes, OSS has their nuances, command line tools have their nuances. Having Google be the company at the receiving and has it's own set of complications. I don't think all the objections apply in all cases.
      - ticviking 4y ago
  - anonymousab 4y ago
    Seems like the simplest compromise is to just force the user to answer the question one way or the other. No default - ask them "do you want to enable telemetry? We'll use it for X..." and only continue the upgrade or install or first-run once they have provided an answer one way or another. Will it cause friction, with users and with tooling and automations? Absolutely. But I think the costs of that friction is not a tremendous ask in terms of avoiding the dark pattern that is defaulting to yes. In a perfect world, at least. In this one, end users are never going to win an argument about telemetry with google-borne systems, and definitely not for actually benign telemetry systems like this.

The idea would include an opt-out. It would probably be easier to use the opt-out rather than maintaining a fork.

by rocqua 4y ago

The idea would include an opt-out. It would probably be easier to use the opt-out rather than maintaining a fork.

jonhohle 4y ago

But the feature should be opt-in to begin with. Opt-out is an anti/dark-pattern that should rightfully be derided.

alkonaut 4y ago
Opt-in greatly reduces the statistical quality of the data. That said, there are many forms of Opt-out. It's one thing to show a checkbox in the setup of a desktop applicatoin saying "send anonymous usage data" and have the checkbox pre-checked. That's a form of opt out, but it's not hidden. It's quite different to have a system enabled which is only possible to switch off by googling a solution or digging in a settings menu. That's also opt-out, but it's a much darker pattern than the pre-checked checkbox. Obviously, a command line tool doesn't have the luxury of an interactive setup, so the same patterns don't apply, but whether or not something is "opt out" or "opt in" isn't the entire story. I find the "default" to be the important thing. Developers need "the default" to be enabled to get reasonable coverage. That doesn't mean it needs to be "secretly" enabled.
- throwntoday 4y ago
  This doesn't change what the parent comment said. Opt-out is inherently a dark pattern. The hope is that the person installing the software doesn't actually read and uncheck the box. It's no different to "install bing toolbar" for example being pre-checked and snuck in to directx.
  - alkonaut 4y ago
    > The hope is that the person installing the software doesn't actually read and uncheck the box Yes. Because you have the "don't care" group being the important group. The users are split into a small group being positive (The would-opt-ins) and a small group being negative (the people arguing it must be opt in) and a large group who don't care. The central "don't care" group is so large that the data is almost useless without them - i.e. you could just as well not have the system at all if you were going to do a full opt-in. So the unchecked box alternative really isn't an alternative.
    - Lio 4y ago
      You've missed out a group there, it's: * Would-opt-ins * Would-opt-outs * Don't-cares * Did-not-know-that-google-are-going-to-run-telemetrys By making it opt-out Google will be conveniently hoovering up the people that would say objects if they knew along with the don't cares.
      - alkonaut 4y ago
        Yes my 3-group would be the case for the checkbox-during-installer-of-desktop-app.
- layer8 4y ago
  The checkbox being pre-checked is still not legal in some countries, exactly because it favors the non privacy protecting option.
  - alkonaut 4y ago
    > The checkbox being pre-checked is still not legal in some countries exactly because it favors the non privacy protecting option I think you are confusing this with systems that gather any PII, and regulations such as the GDPR and similar. This is about collecting data without any PII so any privacy regulation wouldn't apply here.
    - layer8 4y ago
      If the telemetry data is associated with the IP or contains anything that can be used to identify or track the particular Go installation (similar to a browser fingerprint), then it can be considered PII.
      - alkonaut 4y ago
        Of course. But then it's not "anonymous usage statistics" at all is it?
        layer8 4y ago
        I don’t know how they can collect useful statistics when they cannot distinguish between 1000 invocations by the same user/environment vs. one invocation by 1000 different users/environments. And when they can distinguish, then that tracking is prone to fall under personal data processing.
        alkonaut 4y ago
        Most off the shelf systems work with random pseudonyms: You generate a unique random number and store it only on the end user's system. Then you tag each data value with the random id one. These random identifiers do not count as PII so long as it is not possible to tie them to a real identity. So while you are of course required to follow data processing regulations, pseudonymous usage statistics with random identifiers is not against any regulation I know about at least. The lifespan of the pseudonym can be as long or short as you want e.g. last one session, one week, one version etc. But even when completely persistent, they will not constitute PII.
- Lio 4y ago
  > Obviously, a command line tool doesn't have the luxury of an interactive setup, Why would the command line tool not have the option of an interactive setup? Many command line tools ask you to say yes/no to things the first time they are run. Even if you want to reconfigure a tool it shouldn't be difficult to retrigger a decision tree.
  - alkonaut 4y ago
    > Why would the command line tool not have the option of an interactive setup? Typically because (at least if it's already shipped) there are hard expectations about what it will do. E.g. that it shouldn't block waiting for input. That might screw headless/CI uses. A shipped product probably also doesn't have the luxury of using a /noninteractive or /noTelemetry or requiring an env car or similar to block it, because the CI scripts are already written. You can have it ask the user (block waiting for input) if its given a NEW command line option. But you can't do it in the absence of that option. That's why, for a shipped product, it's so much easier to make it opt out. The alternative would be to make it opt in via command line switch or env var - which would obviously be so rare that there is no point in doing it at all.
    - jonhohle 4y ago
      How many CI environment are (or at least should be) connected to the internet to begin with? That almost certainly eliminates the possibility of reproducible builds but also opens all kinds of security issues. (I know sandboxes builds are not common place, but they really should be.)
      - alkonaut 4y ago
        > How many CI environment are (or at least should be) connected to the internet to begin with No idea. If I had to make a guess I'd say 99%?
- jonhohle 4y ago
  Xcode command line tools require a one-time license agreement. FreeBSD ports will open an ncurses based configuration dialog if there are new options. Plenty of Java tools will prompt for JAVA_HOME if they can’t figure out where it is and the JVM forces providing arguments for enabling some license restricted features. Telemetry from a private system should always be opt-in. I find it concerning that developers think they have some default right to data on systems they don’t own without explicitly getting permission. It may be technically possible, it may be statistically necessary, but it’s morally bankrupt and erodes the peer relationship that should exist in open source software.
  - alkonaut 4y ago
    > Telemetry from a private system should always be opt-in. I have to disagree. I think it should be visibly communicated (not snuck in under the radar) but such cases default on should be acceptable so long as it is clearly communicated. Command line systems ARE inherently more difficult than the installer checkbox I'm used to (but by no means impossible to work with). > Xcode command line tools require a one-time license agreement > plenty of Java tools will prompt for JAVA_HOME if they can’t figure out where it is This is easy enough if done from the start, but it's hard to do without breaking existing users's scripts if you have the requirement that "We don't stop and ask for permission in v2.0 if we didn't in v1.0 given the same arguments and environment, as that will break people's builds". And as a user of a command line tool I have to say that requirement seems much more important... This is why it's a good idea to have a /noninteractive switch for command line tools. You can state from v1.0 that without it, it might block at any point in any later version , so any script that doesn't use it made a mistake. > developers think they have some default right to data on systems they don’t own without explicitly getting permission What is explicitly asking here? Is the checked state of a checkbox part of whether it's explicit? > it’s morally bankrupt and erodes the peer relationship that should exist in open source software. Yes, OSS has their nuances, command line tools have their nuances. Having Google be the company at the receiving and has it's own set of complications. I don't think all the objections apply in all cases.
    - ticviking 4y ago
- anonymousab 4y ago
  Seems like the simplest compromise is to just force the user to answer the question one way or the other. No default - ask them "do you want to enable telemetry? We'll use it for X..." and only continue the upgrade or install or first-run once they have provided an answer one way or another. Will it cause friction, with users and with tooling and automations? Absolutely. But I think the costs of that friction is not a tremendous ask in terms of avoiding the dark pattern that is defaulting to yes. In a perfect world, at least. In this one, end users are never going to win an argument about telemetry with google-borne systems, and definitely not for actually benign telemetry systems like this.