Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

191–200 of 314 posts

Re: Transparent telemetry for open-source projects

#191
post #143
post #97

Earlier quoted context omitted.

> opt-in telemetry doesn't work. Then don't do telemetry at all. Google doesn't have a right to data.

Yeah, but they do have right to modify projects that they sponsor as they see fit.

At which point they lose the "right" to claim it's a community project...

Re: Transparent telemetry for open-source projects

#192
post #23

I've been a pretty strong advocate of the idea that analytics should always be minimal, 100% anonymous, aggregated, and open to the public - otherwise it’s spying. This is how we do analytics on our websites today[0][1], and how we plan to do it in games we release in the future. Maybe one day I will start a dedicated FOSS service that people can use for exactly this with some trusted reputation/transparency/auditabi…

Yes. I fundamentally don't care how "good" Go telemetrics would be, because I don't want the FOSS ecosystem as a whole to take any more steps down that slippery slope. There will not be a way back from this.

Re: Transparent telemetry for open-source projects

#193
post #165

There's a lot of strong reactions here, which I don't think are generally unfounded. Telemetry has certainly been misused and will continue to be, but it can also be an invaluable tool for product development. For example, we had a CLI with many commands and flags, some of which were costly to maintain. By adding analytics, we were able to see that literally no one was using certain commands, and we could safely remo…

> Telemetry has certainly been misused and will continue to be, but it can also be an invaluable tool for product development.

This perfectly exemplifies the whole problem. Google views Go as a product which Google is responsible for.

Go is a programming language. Go is critical infrastructure. Go is not a product. Viewing it as such is a fundamental misunderstanding of what Go is to its users.

This will practically implement my choice of programming language going forward. My question will no longer be, "is Go the right choice for this?", but rather, "is a Google product the right choice for this?". The answer is often yes to the former question, and no to the latter question.

Re: Transparent telemetry for open-source projects

#194
post #189
post #167

Earlier quoted context omitted.

> Opt-out is generally rejected by European privacy laws. ...where personal data is involved. It strikes me that this proposal goes to considerable lengths to avoid collecting anything that could be considered personal data.

IANAL but European law is nuanced over whether IP addresses are PII. If I'm not mistaken it's been ruled they are for ISPs, rationale being they have enough other data points that once correlated with IP addresses allow to identify individuals. Whether the same applies to Google (I suppose) is definitely not clear to me.

The proposal explicitly says they don't collect IP addresses or _any_ unique identifiers.

Re: Transparent telemetry for open-source projects

#195
post #73

Earlier quoted context omitted.

The argument for this being opt-in isn't about "it works better", it is about it being ethically correct. There are a ton of things that "don't work" unless you do something unethical: that doesn't mean they are OK, it doesn't mean they should be tolerated, and it doesn't mean the people who do them--and, at the end of the day, it is people who make these decisions: there is a human being who refused to say "no" and…

You're framing this as though the "ethical" choice were obvious, or that there was a person who "knew this was the ethical thing to do, but turned a blind eye". I disagree, I think it's a very contested topic, with lots of discussion whenever it's raised here, with either side possibly being a vocal minority.

Spying on people without their consent is not ethical.

Re: Transparent telemetry for open-source projects

#196
post #193
post #165

There's a lot of strong reactions here, which I don't think are generally unfounded. Telemetry has certainly been misused and will continue to be, but it can also be an invaluable tool for product development. For example, we had a CLI with many commands and flags, some of which were costly to maintain. By adding analytics, we were able to see that literally no one was using certain commands, and we could safely remo…

> Telemetry has certainly been misused and will continue to be, but it can also be an invaluable tool for product development. This perfectly exemplifies the whole problem. Google views Go as a product which Google is responsible for. Go is a programming language. Go is critical infrastructure. Go is not a product. Viewing it as such is a fundamental misunderstanding of what Go is to its users. This will practically…

I guess that begs the question - if Go was an independent project (totally unattached from google) and had the exact same telemetry plans, how would you feel?

Re: Transparent telemetry for open-source projects

#197
post #177

Earlier quoted context omitted.

There are essential, fire-extinguisher-like features. The canonical example is the joke about backup software: if it were developed according to today's standard of telemetry-driven engagement analytics, the restore from backup functionality would be removed because it's used so infrequently. This actually happens sometimes: when developing the demo ".kkrieger", a first-person 3D shooter in 96 KiB, demogroup theprodu…

I think your view of the ways usage stats are used is a bit simplistic. Not everyone remove "underused" features without giving some consideration, even in big corporations. But since you clearly don't like telemetry, you should have a way to reliably switch it off. Here we are on the same page: there must be a well-documented and easy way to switch any telemetry off.

If telemetry is on by default, the vendor obviously wants you to have telemetry on. They are incentivized to make switching it off as difficult as possible, and even pull tricks like turning it back on after a delay of 7 or 30 days or so.

Telemetry should be opt-in, if it's provided at all.

Re: Transparent telemetry for open-source projects

#198
post #80

Oh Google - never stop being you. Not only is it going to be opt-out (because of course it would be coming from Google), I really like the whole "wait a week before sending telemetry" part that just coincidentally has the benefit of sneaking right past people that actively look for suspicious network activity when they've freshly installed something. Am I being uncharitable?

Very popular programming language and IDE have telemetry on by default, VSCode, C#, Java etc ... People act like they discover telemetry in 2023. I don't think it's a big deal, ultimately it's to improve Go and the proposal makes it very easy to disable it ( single env variable ).

What the hell? "People act like they discover telemetry in 2023"? Are we just going to ignore the fact that the issue of companies spying on their users has been a hotly discussed controversial topic since the practice began? Do you think objection to telemetry first appeared in 2023?

Re: Transparent telemetry for open-source projects

#199
post #190
post #161

Earlier quoted context omitted.

This is an incorrect assertion. We have to ask for permission on our SaaS products to collect this data as it's not necessary to collect it for the product to function. The EU GDPR mandates this. Russ Cox is suggesting that there is no permission step and that the data is collected by default. That is the issue.

From my reading focused on this specific issue of the GDPR and the national laws of member states, this is not the case. Opt-in is specifically required for personal information. The telemetry data outlined in the proposal would not fall under this requirement. You can even retain time-limited IP logs with some special caveats. The GDPR is actually quite reasonable and fair. Russ Cox is a very intelligent and effecti…

Google or Russ Cox's reputation is irrelevant. The idea stands alone. I'm merely crediting him with the idea.

I read the proposal. There is no discussion of the legality of this at all. I'd expect anyone with any level of supposed technical competence to consider this in relation to global data protection. I suspect there has been no legal review as mentioned in the thread because I know how slow the lawyers in this space work and the timeline between publishing this and now is too short to have had a conclusive answer.

As for your point about GDPR, I think if you apply your right to withdraw from opt out data collection and what that entails and then ask how this glaring defect is missing from RSC's paper, then you'll see exactly how much privacy consideration really went into this.

Re: Transparent telemetry for open-source projects

#200
post #189

Earlier quoted context omitted.

IANAL but European law is nuanced over whether IP addresses are PII. If I'm not mistaken it's been ruled they are for ISPs, rationale being they have enough other data points that once correlated with IP addresses allow to identify individuals. Whether the same applies to Google (I suppose) is definitely not clear to me.

The proposal explicitly says they don't collect IP addresses or _any_ unique identifiers.

As far as I'm aware/recall, European privacy laws consider any connection back to a telemetry server to count as "collecting" IP addresses, since the telemetry server learns it (even if they pinky swear not to write it down.)
Post reply on HN