4 ms·

> why the option of “we ask the user when they install what they want” is not explored. Because Go == Google, and when has Google "asked the user" before slur

> why the option of “we ask the user when they install what they want” is not explored. Because Go == Google, and when has Google "asked the user" before slurping data? If they are going to do it, it should only ever be on an OPT-IN basis.

mpldr 4y ago
> If they are going to do it, it should only ever be on an OPT-IN basis. They made their case against it, and I can even understand the reasoning behind it. Doesn't mean I have to agree though.
- quectophoton 4y ago
  But still there's programs like Git as an existing example of this kind of "ask the user" thing. Last time I checked: * When you run `git init` without having configured default branch name it warns you with a big wall of text. * When you run `git commit` without having configured a user, it warns you with a big wall of text. * When you run `git pull` without having configured the strategy, it warns you with a big wall of text. As much as I want to give them the benefit of doubt, this really comes off as wanting to silently enable it by default, because they know that if they actually ask in a similar way that `git` does, the answer will be "no".
  - dewey 4y ago
    As much as I like and appreciate git, it's hardly a good example for something with great UX.
    - quectophoton 4y ago
      Exactly, it's an example of a CLI that already messed up its interface, and has actually changed commands (checkout -> switch, has added flags for submodules, etc), and overall has improved since past versions, and still tries to improve. And AFAIK it didn't add telemetry to send used commands to any server, even if that would have been by far the easiest way, given 90% of devs use it and complain about how bad it is. It's an arbitrary percentage, but it gets the point across. The amount of devs using git is probably at least an order or magnitude higher than those using Go. Go, on the other hand, already has decent-ish tooling (at least better Git), but it wants to add opt-out telemetry anyway.
dewey 4y ago
This is very uninteresting data to Google. They are interested in personal data that you can use to optimize targeted ads, not compiler cache miss counts from your local development workflow. The reasoning for not making this opt-in are in the blog post and I find them reasonable.
- mlry 4y ago
  Their reasons are centered on the low returns of opt-in (due to people regularly not changing defaults). They obviously fail to see that people might check their settings and do not want to opt in. And the reason for that is given right after that observation: people have been burned too often by companies and systems that slurp up ever more data way beyond what is necessary for the alleged purpose. Opt-Out is simply not acceptable.
- orbital223 4y ago
  > This is very uninteresting data to Google. It's not about how interesting the data is to them, it's about the hubris of believing they are entitled to every last bit of our data.
  - deafpolygon 4y ago
    Let's not forget the https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog
- TeMPOraL 4y ago
  If you think this data is not interesting to Google, I think you're not using your imagination enough. Even "compiler cache miss counts from your local development workflow" could be used as a signal to optimize ads for development tooling. Or hardware. In general, when looking at telemetry data, you can't stop at asking "what possible use would the org collecting it have for it right now, in their current business model". You need to also ask what use they could potentially have for it in the future, especially combined with other data they have access to. A year from now, or five years from now, or after a pivot, or after partnering with (or buying) a company in a different industry, or after leaking (or selling) it to third parties. When you ask these questions, I think you'll also conclude that enabling telemetry by default and pinky swears they're not doing anything naughy with it is not good enough. You may trust the people doing it now, but as experience shows, business priorities change, people in charge change, but the collected data remains.

mpldr 4y ago

> If they are going to do it, it should only ever be on an OPT-IN basis. They made their case against it, and I can even understand the reasoning behind it. Doesn't mean I have to agree though.

quectophoton 4y ago
But still there's programs like Git as an existing example of this kind of "ask the user" thing. Last time I checked: * When you run `git init` without having configured default branch name it warns you with a big wall of text. * When you run `git commit` without having configured a user, it warns you with a big wall of text. * When you run `git pull` without having configured the strategy, it warns you with a big wall of text. As much as I want to give them the benefit of doubt, this really comes off as wanting to silently enable it by default, because they know that if they actually ask in a similar way that `git` does, the answer will be "no".
- dewey 4y ago
  As much as I like and appreciate git, it's hardly a good example for something with great UX.
  - quectophoton 4y ago
    Exactly, it's an example of a CLI that already messed up its interface, and has actually changed commands (checkout -> switch, has added flags for submodules, etc), and overall has improved since past versions, and still tries to improve. And AFAIK it didn't add telemetry to send used commands to any server, even if that would have been by far the easiest way, given 90% of devs use it and complain about how bad it is. It's an arbitrary percentage, but it gets the point across. The amount of devs using git is probably at least an order or magnitude higher than those using Go. Go, on the other hand, already has decent-ish tooling (at least better Git), but it wants to add opt-out telemetry anyway.

dewey 4y ago

This is very uninteresting data to Google. They are interested in personal data that you can use to optimize targeted ads, not compiler cache miss counts from your local development workflow. The reasoning for not making this opt-in are in the blog post and I find them reasonable.

mlry 4y ago
Their reasons are centered on the low returns of opt-in (due to people regularly not changing defaults). They obviously fail to see that people might check their settings and do not want to opt in. And the reason for that is given right after that observation: people have been burned too often by companies and systems that slurp up ever more data way beyond what is necessary for the alleged purpose. Opt-Out is simply not acceptable.
orbital223 4y ago
> This is very uninteresting data to Google. It's not about how interesting the data is to them, it's about the hubris of believing they are entitled to every last bit of our data.
- deafpolygon 4y ago
  Let's not forget the https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog
TeMPOraL 4y ago
If you think this data is not interesting to Google, I think you're not using your imagination enough. Even "compiler cache miss counts from your local development workflow" could be used as a signal to optimize ads for development tooling. Or hardware. In general, when looking at telemetry data, you can't stop at asking "what possible use would the org collecting it have for it right now, in their current business model". You need to also ask what use they could potentially have for it in the future, especially combined with other data they have access to. A year from now, or five years from now, or after a pivot, or after partnering with (or buying) a company in a different industry, or after leaking (or selling) it to third parties. When you ask these questions, I think you'll also conclude that enabling telemetry by default and pinky swears they're not doing anything naughy with it is not good enough. You may trust the people doing it now, but as experience shows, business priorities change, people in charge change, but the collected data remains.