4 ms·

I am jaded and probably being a little uncharitable. However, I don't know Russ personally so I have no reason to place a high level of confidence that a Googl

I am jaded and probably being a little uncharitable. However, I don't know Russ personally so I have no reason to place a high level of confidence that a Google employee isn't going to make decisions that align more with Google's interests vs privacy interests. Regardless, there are plenty of ways to upgrade the Go tool chain (snaps, distro packages, fetching latest via curl, etc) that won't result in the changes being immediately visible. Given that, I think you are painting an overly optimistic picture of a world though where everyone that cares about this is going to be immediately aware that opt-out telemetry has been added vs a lot of installs being silently swept up into this by sheer ignorance. Also, this is going to require me to go and set environment variables in about a dozen environments to disable the collection and while I can pretty easily manage that task via ansible I'm not happy about having to jump through hoops to turn off telemetry for a freaking compiler tool chain.

agwa 4y ago
> I am jaded and probably being a little uncharitable. However, I don't know Russ personally so I have no reason to place a high level of confidence that a Google employee isn't going to make decisions that align more with Google's interests vs privacy interests. If the nature of this data were different, I would be suspicious too. But it's really hard for me to see how a set of counters (whose names have various protections to ensure they can't contain private information) being sent approximately once a year is going to help with Google's advertising interests (which is what I assume you meant by "Google's interests"; I think they also have an interest in making Go better and the telemetry proposal aligns with that). This is literally the first time I've been OK with telemetry. > Regardless, there are plenty of ways to upgrade the Go tool chain (snaps, distro packages, fetching latest via curl, etc) that won't result in the changes being immediately visible. Given that, I think you are painting an overly optimistic picture of a world though where everyone that cares about this is going to be immediately aware that opt-out telemetry has been added vs a lot of installs being silently swept up into this by sheer ignorance. I agree there will be people who won't notice the disclosure (which will also be in the release notes), but again I tend to think that the people sniffing network traffic after installing a program would also scrutinize release notes instead of just blindly installing upgrades, which is why I find it pretty improbable that Russ' explanation was a pretext. > Also, this is going to require me to go and set environment variables in about a dozen environments to disable the collection and while I can pretty easily manage that task via ansible I'm not happy about having to jump through hoops to turn off telemetry for a freaking compiler tool chain. I think the best suggestion I've seen is that there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application.
- arp242 4y ago
  > there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application. There was a proposal for that some years ago, but that didn't really go anywhere, partially because of the author's rather unpleasant attitude towards projects he wanted to implement it and their overly broad definition of "tracking" (which includes e.g. update checks). Some discussions: https://news.ycombinator.com/item?id=27746587 https://news.ycombinator.com/item?id=27746587 https://lobste.rs/s/htbkqd/console_do_not_track https://lobste.rs/s/htbkqd/console_do_not_track
- JohnFen 4y ago
  > I think the best suggestion I've seen is that there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application. This is a nonstarter, as DNT demonstrated in spades.

agwa 4y ago

> I am jaded and probably being a little uncharitable. However, I don't know Russ personally so I have no reason to place a high level of confidence that a Google employee isn't going to make decisions that align more with Google's interests vs privacy interests. If the nature of this data were different, I would be suspicious too. But it's really hard for me to see how a set of counters (whose names have various protections to ensure they can't contain private information) being sent approximately once a year is going to help with Google's advertising interests (which is what I assume you meant by "Google's interests"; I think they also have an interest in making Go better and the telemetry proposal aligns with that). This is literally the first time I've been OK with telemetry. > Regardless, there are plenty of ways to upgrade the Go tool chain (snaps, distro packages, fetching latest via curl, etc) that won't result in the changes being immediately visible. Given that, I think you are painting an overly optimistic picture of a world though where everyone that cares about this is going to be immediately aware that opt-out telemetry has been added vs a lot of installs being silently swept up into this by sheer ignorance. I agree there will be people who won't notice the disclosure (which will also be in the release notes), but again I tend to think that the people sniffing network traffic after installing a program would also scrutinize release notes instead of just blindly installing upgrades, which is why I find it pretty improbable that Russ' explanation was a pretext. > Also, this is going to require me to go and set environment variables in about a dozen environments to disable the collection and while I can pretty easily manage that task via ansible I'm not happy about having to jump through hoops to turn off telemetry for a freaking compiler tool chain. I think the best suggestion I've seen is that there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application.

arp242 4y ago
> there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application. There was a proposal for that some years ago, but that didn't really go anywhere, partially because of the author's rather unpleasant attitude towards projects he wanted to implement it and their overly broad definition of "tracking" (which includes e.g. update checks). Some discussions: https://news.ycombinator.com/item?id=27746587 https://news.ycombinator.com/item?id=27746587 https://lobste.rs/s/htbkqd/console_do_not_track https://lobste.rs/s/htbkqd/console_do_not_track
JohnFen 4y ago
> I think the best suggestion I've seen is that there should be a single environment variable (e.g. $TELEMETRY) that all programs should respect, to avoid the need to do work for every application. This is a nonstarter, as DNT demonstrated in spades.