Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

151–160 of 314 posts

Re: Transparent telemetry for open-source projects

#151
post #144

Earlier quoted context omitted.

> " What if -every- one of these started doing their own telemetry, their own envvars, etc? " What bad thing are you suggesting would happen if they did? Your computer and internet connection can't handle four thousand strings or four thousand HTTP POSTS, or four MB more disk space of telemetry libraries? I bet it can. This isn't a technical problem, it's a control and consent problem.

I wouldn't be so sure it's not also a technical problem, the limit of execve can be as low as 128kb which for 4,000 strings gives a maximum of 32 characters per NAME=VALUE environment value

Free disk space can be as low as zero, but we don't blame the tool makers for adding an extra 100Kb or 20MB, we blame the computer owner for not having enough disk space to install the thing they chose.

Wrapper scripts for every utility to do

    UTIL_TELEMETRY_OPT_OUT=1 util ...
so they don't need to be set all at once.

Re: Transparent telemetry for open-source projects

#152

Earlier quoted context omitted.

I agree that opt-out is a Bad Thing, but I disagree with this stance. And I think lots of people in the pro-telemetry camp see that there's an ethical issue to be discussed, but they reach a different conclusion. They shouldn't be dismissed so glibly.

Reaching a different conclusion is one thing, but not seeing a dilemma is another. One can always argue that invading a person's autonomy might be necessary given the benefits but seeing no issue is just turning a blind eye.

In the Golang announcements, it's clear that they completely see and understand the dilemma, and have provided a lengthy explanation of why they decided for opt-out anyway.

I respect that. I don't agree with the decision, but it was made with understanding and thought.

Re: Transparent telemetry for open-source projects

#153

Earlier quoted context omitted.

I agree, that's not what I think was extreme about your position. I think you've invented straw men in this comment and your previous comment.

Reading your comment again, I can see it now. I misinterpreted "knew this was the ethical thing to do, but turned a blind eye" as "knew there was an ethical problem, but turned a blind eye". Turns out, my straw man can't read.

Props to you for saying so publicly! I'm not sure if you're unusually open or if I just found the right words to persuade you, but this is a first for me :)

Re: Transparent telemetry for open-source projects

#154

@rsc, if you ever see this, your proposal here means that I will never use any software written in Go ever again, if at all possible. What others have said in this thread about telemetry becoming an "accelerant" will happen. Abuse will happen. Data will be put up for sale. IP's will be logged because users can't verify that they're not. The only thing users can verify is what is sent and to whom. And only if they run…

[deleted]

Re: Transparent telemetry for open-source projects

#155
post #112
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…

What is the argument for opt-out telemetry being unethical?

Because that goes against informed consent.

Opt-out is generally rejected by European privacy laws.

Re: Transparent telemetry for open-source projects

#156

Very much against this. Sure, it sounds naive enough, and can give reasons why. But I have 3,436 items in /usr/bin. What if -every- one of these started doing their own telemetry, their own envvars, etc? If we have to deal with telemetry, then I'd instead hope that there can exist a single telemetry systemwide interface. Not sure how that would be designed or implemented, but would be better than everyone doing their…

maybe the problem is why do you need 3436 binaries there?

Re: Transparent telemetry for open-source projects

#157
post #101

Probably related to[0]. To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually. The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You do…

> opt-in telemetry doesn't work That's too bad. Guess you don't get any telemetry data if you want to develop ethical open software. The answer isn't to bend your ethics. If a take a dollar from everyone but it's opt out, that's just theft with extra steps. If I make it opt in, nobody is going to give me the dollar, but that doesn't make opt out morally justifiable.

Why is it unethical? People in every day life constantly assume things about one another and take actions that affect one another without asking first, and this is a practical necessity, so if the reason is that "you may not do anything without me tell you its ok" I don't think thats a defensible position.

Re: Transparent telemetry for open-source projects

#158

Earlier quoted context omitted.

> The idea of telemetry is being able to prioritize the work that will be most widely useful. It does sort of hinge on the highly suspect assumption that usefulness is correlated with use. An obvious counter-example to this is something like a fire-extinguisher, which will in the ideal case just sit on a wall until it's use-by date passes and then it's discarded having never been used; or on the flip side, an incredi…

All this boils down to "an unskilled engineer will misinterpret data even if they have it". I'll assume the Go team knows what they're doing, based on their track record so far. There's a lot of very simple questions you can answer very reliably, too, like "what proportion of the users are still using a certain compatibility flag".

> I'll assume the Go team knows what they're doing, based on their track record so far.

Funny, I’d assume the exact opposite. After all much of the understanding of privacy and statistics at scale was developed after 1980.

Re: Transparent telemetry for open-source projects

#159

@rsc, if you ever see this, your proposal here means that I will never use any software written in Go ever again, if at all possible. What others have said in this thread about telemetry becoming an "accelerant" will happen. Abuse will happen. Data will be put up for sale. IP's will be logged because users can't verify that they're not. The only thing users can verify is what is sent and to whom. And only if they run…

What world do you live in?

Re: Transparent telemetry for open-source projects

#160
post #80

Earlier quoted context omitted.

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 ).

Totally agree. Telemetry has been around and matured and benefits users. I’m not sure the benefits for Go would be as significant as other software but, really, why not?

> Telemetry has been around and matured and benefits users.

Does it? Telemetry mostly seems used to justify removing features I need on grounds that they’re little used.

As an other user noted, if telemetry is your yardstick, the average backup software removed the “restore” feature because that’s barely ever used.

Post reply on HN