8 ms·

The design of transparent telemetry

deleted 4y ago
[deleted]
saagarjha 4y ago
IMO the only part of this article that is general enough to discuss is the bit about opt-out telemetry; everything else is just slapping technical solutions and attempts at preserving privacy on top of an opt-out system. On that front, I find it confusing why the option of “we ask the user when they install what they want” is not explored. It’s given as an example in the article, and then there’s a whole section about how they want to give people sufficient notice on their website and how it would be bad to report stats before people could realize it’s turned on. Why not just tell them when they install and let them change it then and there?
- traceroute66 4y ago
  > 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.
- josephcsible 4y ago
  > I find it confusing why the option of “we ask the user when they install what they want” is not explored. I don't. It's because they know that most people don't want this, and will say no if asked, but won't realize they need to opt out if it's just silently enabled by default.
  - alkonaut 4y ago
    Most users don’t want to send telemetry. But most users also want a system built by people who understand how users use it.
    - ad404b8a372f2b9 4y ago
      You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.
      - eestrada 4y ago
        I would argue that using your own product and talking to your customers is the only way to make good and useful products. Telemetry may have a good use case (although I struggle to find one), but it isn't a substitute for dogfooding and direct customer interaction.
        deafpolygon 4y ago
        The true use case here is to get you used to the idea of telemetry in your tool chain, then move the goal post further down the road. In a few years, it'll be encouraged to put telemetry in your library ("Why?" "We've already had it in the tool chain this isn't any different!") then eventually, have every application sending telemetry data to Google's servers. If you think this is ridiculous, remember they built Chrome with telemetry embedded .. why? Not for improving services. To build better targeted advertising. Remember Android OS? Yes. But there's still push back and the primary group of people resisting this at large are developers and the more technically inclined.
deleted 4y ago
[deleted]
rapnie 4y ago
The final link in the post is relevant to mention. Pointing to the Github discussion related to this idea: https://github.com/golang/go/discussions/58409 https://github.com/golang/go/discussions/58409
- speedgoose 4y ago
  Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. I know that managing a community online is difficult especially when the community is against a decision, but I think Google employees should communicate better. The most straightforward path for them is to announce that they have changed their mind about telemetry. Or everyone should use Rust instead, obviously.
  - mort96 4y ago
    I'm guessing your last comment is a joke, but honestly, that's sort of the consequence for at least some of my projects. I like Go, and I have a prototype of something written in Go. Now that I understand the domain better, I want to rewrite it; the initial plan was to do the rewrite in Go as well, but honestly, I don't want to endorse Google's telemetry and push it onto my users. So the rewrite is going to be Rust instead.
    - verdverm 4y ago
      This is not adding telemetry to your code, it is very minimal telemetry within the go toolchain. They expect a user will send a week's worth of counters to the server once a year on average. It does not push telemetry on your users
      - none_to_remain 4y ago
        If mort96 is writing libraries it does
        mynameisvlad 4y ago
IshKebab 4y ago
It's a good idea as long as they actually have some good motivation for capturing data. If it's just "we're curious" then I don't think that is good enough.
- verdverm 4y ago
  Many of the questions they hope to answer are here https://research.swtch.com/telemetry-uses https://research.swtch.com/telemetry-uses
  - IshKebab 4y ago
    Ah great link. Seems like a very reasonable list to me.
- deafpolygon 4y ago
  https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog
deleted 4y ago
[deleted]
dang 4y ago
Recent and related: Transparent telemetry for open-source projects - https://news.ycombinator.com/item?id=34707583 https://news.ycombinator.com/item?id=34707583 - Feb 2023 (297 comments) also: Google's Go may add telemetry that's on by default - https://news.ycombinator.com/item?id=34744948 https://news.ycombinator.com/item?id=34744948 - Feb 2023 (37 comments)
ReactiveJelly 4y ago
Opt-out sucks.
- kaba0 4y ago
  Depends, it is great for organ donation.
vlovich123 4y ago
> The server would necessarily observe the source IP address in the TCP session uploading the report, but the server would not record that address with the data, a fact that can be confirmed by inspecting the reporting server source code (the server would be open source like the rest of Go) or by reference to a stated privacy policy like the one for the Go module mirror, depending on whether you lean more toward trusting software engineers or lawyers. A company could also run their own HTTP proxy to shield individual system’s IP addresses and arrange for employee systems to set GOTELEMETRY to the address of that proxy. It may also make sense to allow Go module proxies to proxy uploads, so that the existing GOPROXY setting also works for redirecting the upload and shielding the system’s IP address. I wonder if Apple’s Private Relay [1] mechanism might be a safer path that doesn’t rely on operators actually running the open source version verbatim nor on the privacy policy. Disclaimer: I work at Cloudflare. [1] https://blog.cloudflare.com/icloud-private-relay/ https://blog.cloudflare.com/icloud-private-relay/

deleted 4y ago

[deleted]

IMO the only part of this article that is general enough to discuss is the bit about opt-out telemetry; everything else is just slapping technical solutions and attempts at preserving privacy on top of an opt-out system. On that front, I find it confusing why the option of “we ask the user when they install what they want” is not explored. It’s given as an example in the article, and then there’s a whole section about how they want to give people sufficient notice on their website and how it would be bad to report stats before people could realize it’s turned on. Why not just tell them when they install and let them change it then and there?

traceroute66 4y ago
> 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.
josephcsible 4y ago
> I find it confusing why the option of “we ask the user when they install what they want” is not explored. I don't. It's because they know that most people don't want this, and will say no if asked, but won't realize they need to opt out if it's just silently enabled by default.
- alkonaut 4y ago
  Most users don’t want to send telemetry. But most users also want a system built by people who understand how users use it.
  - ad404b8a372f2b9 4y ago
    You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.
    - eestrada 4y ago
      I would argue that using your own product and talking to your customers is the only way to make good and useful products. Telemetry may have a good use case (although I struggle to find one), but it isn't a substitute for dogfooding and direct customer interaction.
      - deafpolygon 4y ago
        The true use case here is to get you used to the idea of telemetry in your tool chain, then move the goal post further down the road. In a few years, it'll be encouraged to put telemetry in your library ("Why?" "We've already had it in the tool chain this isn't any different!") then eventually, have every application sending telemetry data to Google's servers. If you think this is ridiculous, remember they built Chrome with telemetry embedded .. why? Not for improving services. To build better targeted advertising. Remember Android OS? Yes. But there's still push back and the primary group of people resisting this at large are developers and the more technically inclined.

deleted 4y ago

[deleted]

rapnie 4y ago

The final link in the post is relevant to mention. Pointing to the Github discussion related to this idea: https://github.com/golang/go/discussions/58409 https://github.com/golang/go/discussions/58409

speedgoose 4y ago
Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. I know that managing a community online is difficult especially when the community is against a decision, but I think Google employees should communicate better. The most straightforward path for them is to announce that they have changed their mind about telemetry. Or everyone should use Rust instead, obviously.
- mort96 4y ago
  I'm guessing your last comment is a joke, but honestly, that's sort of the consequence for at least some of my projects. I like Go, and I have a prototype of something written in Go. Now that I understand the domain better, I want to rewrite it; the initial plan was to do the rewrite in Go as well, but honestly, I don't want to endorse Google's telemetry and push it onto my users. So the rewrite is going to be Rust instead.
  - verdverm 4y ago
    This is not adding telemetry to your code, it is very minimal telemetry within the go toolchain. They expect a user will send a week's worth of counters to the server once a year on average. It does not push telemetry on your users
    - none_to_remain 4y ago
      If mort96 is writing libraries it does
      - mynameisvlad 4y ago

IshKebab 4y ago

It's a good idea as long as they actually have some good motivation for capturing data. If it's just "we're curious" then I don't think that is good enough.

verdverm 4y ago
Many of the questions they hope to answer are here https://research.swtch.com/telemetry-uses https://research.swtch.com/telemetry-uses
- IshKebab 4y ago
  Ah great link. Seems like a very reasonable list to me.
deafpolygon 4y ago
https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog

deleted 4y ago

[deleted]

dang 4y ago

Recent and related: Transparent telemetry for open-source projects - https://news.ycombinator.com/item?id=34707583 https://news.ycombinator.com/item?id=34707583 - Feb 2023 (297 comments) also: Google's Go may add telemetry that's on by default - https://news.ycombinator.com/item?id=34744948 https://news.ycombinator.com/item?id=34744948 - Feb 2023 (37 comments)

ReactiveJelly 4y ago

Opt-out sucks.

kaba0 4y ago
Depends, it is great for organ donation.

vlovich123 4y ago

> The server would necessarily observe the source IP address in the TCP session uploading the report, but the server would not record that address with the data, a fact that can be confirmed by inspecting the reporting server source code (the server would be open source like the rest of Go) or by reference to a stated privacy policy like the one for the Go module mirror, depending on whether you lean more toward trusting software engineers or lawyers. A company could also run their own HTTP proxy to shield individual system’s IP addresses and arrange for employee systems to set GOTELEMETRY to the address of that proxy. It may also make sense to allow Go module proxies to proxy uploads, so that the existing GOPROXY setting also works for redirecting the upload and shielding the system’s IP address. I wonder if Apple’s Private Relay [1] mechanism might be a safer path that doesn’t rely on operators actually running the open source version verbatim nor on the privacy policy. Disclaimer: I work at Cloudflare. [1] https://blog.cloudflare.com/icloud-private-relay/ https://blog.cloudflare.com/icloud-private-relay/