7 ms·
I mean, some folks in the thread were absolutely arguing in bad faith. A lot of people just go ahead with the "telemetry=bad" message + critique of telemetry i
by cube2222 4y ago
I mean, some folks in the thread were absolutely arguing in bad faith.
A lot of people just go ahead with the "telemetry=bad" message + critique of telemetry in general without even taking a look at the actual proposal[0] (which has some important points regarding collection frequency, data shared, and architecture). Not saying there should be no critique, but blanket statements that often criticize aspects that are irrelevant here don't help.
They're really trying to approach this in a way that, to me, is as reasonable and transparent as effectively possible (yes, I'm on the side of "opt-in telemetry doesn't work because of the majority of people who don't care either way; won't turn off if prompted, won't turn on either", so being opt-in is in fact unreasonable to me).
The Go toolchain already in a sense "calls home" by default to the Go module proxy hosted by Google.
Anyway, it's open source, they're the maintainers, it's up to them, while if you want, you can fork it. Telemetry is immensely useful to understand what features or technical improvements are worth prioritizing to benefit the actual average user the most, and not just the vocal minority. Telemetry being opt-in breaks this by once again prioritizing the vocal minority that turns it on.
[0]: https://research.swtch.com/telemetry-intro https://research.swtch.com/telemetry-intro
- ocdtrekkie 4y agoThe problem with opt-out telemetry is that as soon as you admit people won't voluntarily turn it on, you've admitted it's a user hostile behavior. The usability of opt-out doesn't override the reality that it's not ethical to do it. I think if the Go authors do move forward with this proposal in any form, a fork is guaranteed. I've heard multiple sources express interest in doing so already.
- cube2222 4y ago> The problem with opt-out telemetry is that as soon as you admit people won't voluntarily turn it on, you've admitted it's a user hostile behavior. That is in fact not the case. This is just one possible explanation for users not turning it on, one that I don't believe is even close to a meaningful amount in the grand scale of things. As I wrote in the first message, a huge amount of people don't care either way. They won't turn it off if they're prompted, but they also wouldn't bother turning it on. They just don't care. I'm one of these people.
- bheadmaster 4y ago> As I wrote in the first message, a huge amount of people don't care either way Do you have any data to support that claim? Anecdotally, almost all programmers I've spoken to have expressed some kind of complaint about how much data all our devices collect these days. Many of them even saying that they're afraid to speak their mind on the Internet because they know someone might connect their words to their true identity. A large number of non-programmers have mentioned to me how freaked out they are by their Android phones showing them ads for things they've just mentioned in proximity of their phones for the first time. Considering the massive surveillance we're under, I think that "most people care, and don't want telemetry if given the choice" is much more precise than "most people don't care".
- hardware2win 4y agoYou seems to conflate telemetry with spying Uploading crash log to devs to help them fix bugs Or stats about project sizes So they are aware how their users use their soft and can optimize
- bheadmaster 4y agoWhat is the exact difference between spying and telemetry that user hasn't consented to?
- acdha 4y agoIf we consider the dictionary definition spying has a sense of personal and private information being collected. For telemetry, one of the first questions would be whether the data being collected is the same — for example, something like the version of the C compiler you have installed doesn't seem like nearly as sensitive. The other part is the question of exactly what consent means in this context. If I sneak into your house, I'm spying. If I record what you do when visiting my house, that's arguably still spying. If I say I'm giving you a free meal but at the bottom of the menu there's a warning that I use statistics about which meals are the most popular unless you ask me not to, that doesn't feel like it's in the same category as the previous two even if there's a pretty strong argument that it's best to ask you the first time you show up.
- mattmcknight 4y ago> as you admit people won't voluntarily turn it on, you've admitted it's a user hostile behavior That is presuming people aren't turning it on because they don't like it, while the reason they aren't turning it on could be they are lazy and don't want to do any extra work. If you had a HTML sanitizer that most people weren't turning on, you might just turn it on by default to improve safety (like Rails did at one point). Just because people weren't turning something on themselves doesn't make turning it on by default "hostile".
- anonymousab 4y ago> That is presuming people aren't turning it on because they don't like it, while the reason they aren't turning it on could be they are lazy and don't want to do any extra work The solution in these scenarios is to simply ask the user, with no default, whether they want telemetry to be enabled or disabled. To do so in a modal or required dialogue in fresh install and the update in question. If the telemetry is worth changing defaults to you then IMO it should be worth a bit of friction to introduce it more ethnically.
- cube2222 4y agoI think a lot of users don't actually interact directly with the CLI. Think IDEs, editors, CI/CD. You'd be cutting them out, again skewing the stats heavily.
- anonymousab 4y agoThat's true. I think this would therefore need to be a bit of a breaking change for that tooling - systems that integrate with Go would need to be updated to deal with this prompt. Whether that's showing it to users or autofilling an answer with a --telemetry==x flag, that's up to them and their community. Is that painful? Yes. Would it turn some people away from Go through this kind of friction? Sure. IMO those kinds of costs and pain points should be necessary considerations of adding telemetry. Worth at least a minor version change, and therefore not too crazy that it would cause some annoyance.
- 4y ago
- arp242 4y ago> The Go toolchain already calls home by default to the Go module proxy hosted by Google. I don't think it's fair to describe the Go proxy as "calls home"; no one says that about Rubygems, PyPI, npm, or any other package tool. If anything, the Go proxy is the only package system that actually allows disabling it quite easily and pain-free. Try using Ruby without rubygems or React without npm: no doubt possible, but it will take a lot more effort.
- cube2222 4y agoWell, it allows you to track which packages are used how much and gather ip addresses of your users. IP addresses being the only "personal" data the new telemetry proposal would plausibly be able to gather as well, which a lot of folks are complaining about. Just to be clear, I don't think the Go module proxy is a bad thing, just saying that we've already crossed that "threshold" of potential personal data collection long ago.
- Thaxll 4y agoAre you saying that package mgmt solution should not use network to download actual packages?
- cube2222 4y agoNope, I think the go module proxy is just fine. See my other response[0] for an explanation of what I meant. [0]: https://news.ycombinator.com/item?id=34773848 https://news.ycombinator.com/item?id=34773848
- bmacho 4y agoIt definitely only should use network when I invoke the download package command.
- nishs 4y agoNo, but the go tool/package manager doesn’t necessarily, by default, have to proxy each requested module through Google run servers. It can fetch modules directly from the source. That said, I don’t think that the go tool’s current behavior in regards to the module proxy server can be considered as phoning home. The proposed metrics collection however absolutely would be bad phoning home behavior.
- groestl 4y ago> The Go toolchain already calls home by default It's doing that to provide a functionality required by the user, which results in informed consent. If you do computing without a user's informed consent, you're building malware.
- the_gipsy 4y ago> I mean, some folks in the thread were absolutely arguing in bad faith. A lot of people just go ahead with the "telemetry=bad" message + critique of telemetry in general without even taking a look at the actual proposal It is still telemetry, other platform's toolchains dont have it, it's not bad faith for rejecting it. > Anyway, it's open source, they're the maintainers, it's up to them, while if you want, you can fork it. Yea, so Rust it is then.
- John23832 4y ago> Yea, so Rust it is then. As much as I like both Go and Rust, the jump between the two is not that easy.
- dustedcodes 4y ago> It is still telemetry, other platform's toolchains dont have it, it's not bad faith for rejecting it. .NET enters the room
- indrora 4y agoI've heard plenty of back and forth about adding telemetry to the Rust compiler because of hard to spot bugs. LLVM, GCC, etc. mostly depend on the crash reporter from distributions, and I know several Clang devs who have been thinking about adding some additional telemetry. No I won't mention names here because I do not want the innocent to be harassed because I posted on fucking hacker news.
- somethingreen 4y agoOpt-in telemetry not executing for users who would like it to be executing, because they don't know about it or forgot, makes it an under-advertised feature. Opt-out telemetry executing for users who would not like it to be executing, because they don't know about it or forgot, makes it a spyware. The rest of the discussion only makes sense to have if you agree there are circumstances when implementing spyware is justified.
- pierrebai 4y agoToo bad the linked article arguments are of poor quality and unconvincing. There was a bug on MacOS that ended-up requiring XCode to be install in order for the Go compiler to work? That example is bad because: 1. it was going to be very obvious real quick 2. it did get discovered and fixed without telemetry. ... and both of my points above are irrelevant. Why? Because the problem raised here is not if telemetry is useful or not. It's not even if telemetry is good or bad. It's that discussions about telemetry silenced people who were against it. Your point is that people should not be allowed to raise arguments that have not been approved as valid. I mean, the simplest reformulation is that "if we think you're wrong you will not be allowed to speak." For real? Being wrong means you're not allowed to participate? (And by wrong, I mean "deemed wrong by the people in power to ban others.")