121–130 of 314 posts
Now the tool has generated thousands of log messages that it can't phone home.
And so it must be silenced, since it is cluttering up the logs, generating false alerts, etc.
Please, no more.
Earlier quoted context omitted.
Still, opt-out is just inacceptable. At least with a mechanism which can easily fail, like setting an environment variable. This basically forces you to wrap the go tool in a script which ensures the environment variable to be set. As this seem to cache the results, another option is to fiddle with the cache to report bogus information.
You can set env variable for the go toolchain with a command such as: go env -w TELEMETRY=off which will be written to disk and use by the go cli.
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-out telemetry won't work when people send false data to the servers.
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…
>Longer answer about opt-out generally, copied from mail I sent to golang-dev.
> I wrote a little about this at https://research.swtch.com/telemetry-design#opt-out. Just to quote the beginning:
“An explicit goal of this design is to build a system that is reasonable to have enabled by default, for two reasons. First, the vast majority of users do not change any default settings. In systems that have collection off by default, opt-in rates tend to be very low, skewing the results toward power users who understand the system well. Second, the existence of an opt-in checkbox is in my opinion too often used as justification for collecting far more data than is necessary. Aiming for an opt-out system with as few reasons as possible to opt out led to this minimal design instead. Also, because the design collects a fixed number of samples, more systems being opted in means collecting less from any given system, reducing the privacy impact to each individual system.”
> To elaborate, one of the core things I believe about designing a system like Go is that it needs to ship with the right defaults, rather than require users to reconfigure the defaults to get best practices for using that system. For example, Go ships with use of the Go module mirror (proxy.golang.org) enabled by default, so that users get more reliable builds out of the box. Similarly, Go ships with the use of the checksum database also enabled by default, so that users get verified module downloads out of the box. We know that most users don't want to and probably won't spend time reconfiguring the system: they trust us to set it up right instead. Of course, that implies a responsibility to actually look out for users' best interests, and we take that very seriously. There are important privacy concerns about the module mirror and about the checksum database, despite their clear benefits, so we designed those systems to address as many of those concerns as possible. Among the decisions we made to improve privacy there: (1) GOPROXY can proxy both the module mirror and the checksum database, (2) we published a very clear privacy policy (proxy.golang.org/privacy), (3) we introduced the concept of a tiled transparency log to keep log fetches from exposing a potential tracking signal.
> Moving back to telemetry, enabling telemetry does not confer the same kind of direct benefits to users as the module mirror and the checksum database do. Instead the direct benefits it confers fall on other users: (1) allowing your Go installation to participate in the system means other installations participate just a little bit less, thanks to sampling, and (2) allowing your system to send usage information strengthens the signal from others with similar usage. There is still an important indirect benefit: one system opted out won't have much of an impact, but 99% of systems opted out has a huge impact, and that leads to mistakes like the ones I mentioned in the first blog post, which do make Go worse for you.
> Like with the module mirror and checksum database, there are good privacy concerns to telemetry despite the clear benefits, so the design of transparent telemetry aims to address as many of those as possible. The bullet list in the GitHub discussion (also at the end of the blog post) enumerates the most important ones.
> Most people leave defaults alone or make intuitive guesses about what they want. That's totally reasonable: no one wants to spend half an hour learning the details of each specific setting. But my goal for the system is that if I did spend half an hour explaining how the system worked, then the vast majority of users would agree with the default and see no reason to opt out. Of course, some people will always opt out on general principle, and perhaps there are others who would opt in to some systems but not this one. For those people, my goal is simply to make the opt-out as easy and effective as possible. That's why opting out is just an environment variable (GOTELEMETRY=off) or a single command (go env -w GOTELEMETRY=off), and there's a quiet period of at least a week after installation to give plenty of opportunity to opt out before there's any chance of data being sent.
> I expect that this will not change your mind, and that you and a few others will still believe the telemetry should be opt-out. I accept that: I don't expect to convince everyone about this point. But I hope this helps explain how I am thinking about the decision.
Earlier quoted context omitted.
Off-by-default in a scale likely means that there is no telemetry at all. I would not cancel a guy or programming language based on just suggesting that. He has given a lot of though for that if you read the blog posts.
If a take a dollar from everyone but it's opt out, that's still theft. If I make it opt in, nobody is going to give me the dollar, but that doesn't make opt out morally justifiable.
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…
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 packet inspection. Most users don't.
(Edit: I just realized that users may not even be able to tell who data is sent to because of proxies or the original collector selling the data.)
I have no reason to believe your personal motives are anything but pure; however, this capability will not just be in your hands. It will be in the hands of anyone with less-than-pure motives.
I applaud your efforts to make telemetry more transparent, but they are destined to fail.
When it comes to figuring out how users use software, the only thing to do legwork. Ask your users. Watch them if they'll let you do user studies. Pay non-users to use the software for a user study and put them through all situations, including rare ones.
This is the same thing we programmers tell the police to do when the police whine about end-to-end encryption: do old-fashioned legwork. Why should we, as programmers, demand that of police when we give ourselves tools to violate the privacy of users in the exact same way that police want?
Yes, that's right, the exact same way. Telemetry is a backdoor on a private conversation between a user and a machine.
Just do the work. I'm pretty sure Google has the money to do so.
You may respond that this is for Open Source developers to get data on their users. Well, if those developers are hobbyists, they don't have time to crunch data, and they're probably scratching an itch. If they are not hobbyists, they are paid and should do the legwork.
There is no excuse for telemetry. Just do the work.
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…
And opt-in.
> I also think that Go being a product (it is, whether you like that word or not) makes it more fair to desire analytics of this form.
Not by stealing it.
Google really can’t help themselves, to stick telemetry in anything.