The design of transparent telemetry
research.swtch.com
The design of transparent telemetry
1–10 of 74 posts
Re: The design of transparent telemetry
#2[deleted]
Re: The design of transparent telemetry
#3IMO 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?
Re: The design of transparent telemetry
#4IMO 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 abou…
> 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.
Re: The design of transparent telemetry
#5[deleted]
Re: The design of transparent telemetry
#6IMO 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 abou…
> 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.
> 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.
Re: The design of transparent telemetry
#7Earlier quoted context omitted.
> 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.
> 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.
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".
Re: The design of transparent telemetry
#8IMO 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 abou…
> 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.
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.
Re: The design of transparent telemetry
#9The 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
Re: The design of transparent telemetry
#10Earlier quoted context omitted.
> 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.
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 wa…
As much as I like and appreciate git, it's hardly a good example for something with great UX.