Google's Go May Add Telemetry That's On By Default (theregister.com) 75
Russ Cox, a Google software engineer steering the development of the open source Go programming language, has presented a possible plan to implement telemetry in the Go toolchain. However many in the Go community object because the plan calls for telemetry by default. The Register reports: These alarmed developers would prefer an opt-in rather than an opt-out regime, a position the Go team rejects because it would ensure low adoption and would reduce the amount of telemetry data received to the point it would be of little value. Cox's proposal summarized lengthier documentation in three blog posts.
Telemetry, as Cox describes it, involves software sending data from Go software to a server to provide information about which functions are being used and how the software is performing. He argues it is beneficial for open source projects to have that information to guide development. And the absence of telemetry data, he contends, makes it more difficult for project maintainers to understand what's important, what's working, and to prioritize changes, thereby making maintainer burnout more likely. But such is Google's reputation these days that many considering the proposal have doubts, despite the fact that the data collection contemplated involves measuring the usage of language features and language performance. The proposal isn't about the sort of sensitive personal data vacuumed up by Google's ad-focused groups. "Now you guys want to introduce telemetry into your programming language?" IT consultant Jacob Weisz said. "This is how you drive off any person who even considered giving your project a chance despite the warning signs. Please don't do this, and please issue a public apology for even proposing it. Please leave a blast radius around this idea wide enough that nobody even suggests trying to do this again."
He added: "Trust in Google's behavior is at an all time low, and moves like this are a choice to shove what's left of it off the edge of a cliff."
Meanwhile, former Google cryptographer and current open source maintainer Filippo Valsorda said in a post to Mastodon: "This is a large unconventional design, there are a lot of tradeoffs worth discussing and details to explore," he wrote. "When Russ showed it to me I made at least a dozen suggestions and many got implemented."
"Instead: all opt-out telemetry is unethical; Google is evil; this is not needed. No one even argued why publishing any of this data could be a problem."
Telemetry, as Cox describes it, involves software sending data from Go software to a server to provide information about which functions are being used and how the software is performing. He argues it is beneficial for open source projects to have that information to guide development. And the absence of telemetry data, he contends, makes it more difficult for project maintainers to understand what's important, what's working, and to prioritize changes, thereby making maintainer burnout more likely. But such is Google's reputation these days that many considering the proposal have doubts, despite the fact that the data collection contemplated involves measuring the usage of language features and language performance. The proposal isn't about the sort of sensitive personal data vacuumed up by Google's ad-focused groups. "Now you guys want to introduce telemetry into your programming language?" IT consultant Jacob Weisz said. "This is how you drive off any person who even considered giving your project a chance despite the warning signs. Please don't do this, and please issue a public apology for even proposing it. Please leave a blast radius around this idea wide enough that nobody even suggests trying to do this again."
He added: "Trust in Google's behavior is at an all time low, and moves like this are a choice to shove what's left of it off the edge of a cliff."
Meanwhile, former Google cryptographer and current open source maintainer Filippo Valsorda said in a post to Mastodon: "This is a large unconventional design, there are a lot of tradeoffs worth discussing and details to explore," he wrote. "When Russ showed it to me I made at least a dozen suggestions and many got implemented."
"Instead: all opt-out telemetry is unethical; Google is evil; this is not needed. No one even argued why publishing any of this data could be a problem."
How to alienate your software community - 101 (Score:5, Funny)
This is a great class held by Google. Lots of learnings in there.
Short term opt-in (Score:2)
I don't know why more software doesn't offer a "30-day temporary opt-in" feature. The software could be allowed to send telemetry data for 30 days, then thank the user for temporarily allowing it, confirm it has turned off, and inform them they will need to opt-in again if they want to allow another 30-day period.
There is some open source software I would be willing to grant a temporary opt-in so they can gather information during the initial learning period, and I would be comfortable knowing it wasn't a
Re: (Score:3)
All they had to do is tack on a community support feature. Allow us to take your code and if you have any problem with it, just log in here and show the world your problem and the community will help you.
Think of it as a StackOverflow without the option to completely screw up the formatting of your code when you copy/paste it there for answers.
Doesn't cost them anything since the whole question/answer thing will be handled by the community, maybe spread a rumor that Google is using this as a recruitment too
Re: (Score:2)
That's lovely but largely unrelated to what is being proposed. It wouldn't help with their main goals at all.
Re: (Score:2)
If you see a bright side on something when everything around you looks grim and dark, don't rejoice yet, it may well be the oncoming freight train.
Re: (Score:2)
It's also against the law in plenty of jurisdictions, where affirmative opt-in is required, and where minors cannot give legal consent.
Doesn't affect me though - go has always been a shit language in my books ... both it and Google can go fuck themselves on this one.
Re: (Score:2)
Actually, I think I might rather like the language. But I find the toolchain unusable. This doesn't make me think more highly of it.
Re: (Score:3)
But I find the toolchain unusable.
That's...definitely a reflection of you, not the toolchain. Even if you need a full IDE for some reason, there are several available.
Re: (Score:2)
FWIW, the IDE that I prefer is geany.
OTOH, I prefer make over cmake, so my tastes are definitely not the prevailing ones.
Re: (Score:2)
Re: (Score:2)
I'm not certain that I could use the go toolchain, as I didn't use it long enough. I didn't like the way it's tied into the internet, so I didn't bother fighting through the initial learning curve.
(As an aside, I notice that Rust has the same kind of presumption of internet access, so this may be the current style of things. I prefer to import the source code that I want, and only use that code. This applies to languages, too. I want the thing to work well when not connected to the internet. Clearly Ja
Re: (Score:2)
I didn't like the way it's tied into the internet, so I didn't bother fighting through the initial learning curve.
afaik, if you have the libraries downloaded, you doesn't need internet access (like any other language). If it does, that is truly a breaking point, I agree.
Re: (Score:2)
IF you have the libraries downloaded, I don't believe (but didn't check) that you need the internet connection. You may need to specify particular versions that you've downloaded. But, IIUC, the toolchain itself wants to do the downloading. And wants to decide when to do it.
There were lots of other things that seemed to me misfeatures, and, in the end, I just didn't feel like fighting through them when there were alternatives that I liked better.
Re: (Score:2)
The sad thing is I actually read his blog post and he makes some decent points. Certainly worthy of debate. There won't be any though, only outage and instant rejection.
For example, he proposes that all telemetry data would be published. Nothing hidden, all available to everyone. The actual data collected would be publicly discussed first, and limited to only what is necessary to generate particular stats. No PII, no tracking, just stuff like ratios of how often internal language features are used, to deter
Re: (Score:2)
Take all of that with a huge grain of salt. Even if it legitimately begins that way, it could very well simply be the leading edge of something worse. It's easy to make something seriously bad seem to be benign by only emphasizing the positives. But once that beach head has been established, the bad parts start to slowly appear.
I have no idea if there is anything malignant hiding in this proposal, but my trust in Google is at an all time low.
Re:How to alienate your software community - 101 (Score:5, Insightful)
There won't be any though, only outage and instant rejection.
Perhaps, but it is a well-earned first reaction, not to mention, the most rational one.
If you are wrong in your outrage, then the project misses out on data that it went without to this point, and survived.
If you assume good faith, on the other hand, and are wrong, the data of millions of people are irretrievably siphoned, with the bell unable to be unrung. Add to this the history of the entities involved, and knee-jerk outrage is really the only reaction that makes logical sense. I do not think a benefit of the doubt has really been earned.
The risk is skewed overwhelmingly in one direction.
As such, the reaction the most rational one, imho.
Re: (Score:2)
The reaction is irrational because it ignores the obvious and best option: find out what is actually being proposed by reading TFA.
The proposal doesn't rely on good faith, it explicitly ensures that everything is verifiable and rejectable later. If you don't trust them not to accept rejection, you reaction only ensues you can't have any influence at all, and won't stop them doing it anyway.
Your supposedly rational response is actually the worst and least rational of them all.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
The sad thing is I actually read his blog post and he makes some decent points. Certainly worthy of debate. There won't be any though, only outage and instant rejection.
As it should be, this IS outrageous and self-defeating.
For example, he proposes that all telemetry data would be published. Nothing hidden, all available to everyone. The actual data collected would be publicly discussed first, and limited to only what is necessary to generate particular stats. No PII, no tracking, just stuff like ratios of how often internal language features are used, to determine how important they are.
How would Google feel if all that data related to their developers was being sent to a different company they had no control over? Yea I thought so.
We should at least entertain the idea.
We should reject it outright with no further thought or discussion.
Re: (Score:2)
See, this is what I'm talking about. You don't even know what he's arguing, and your point about "data related to their developers" is completely irrelevant because that's not what is being suggested at all.
At least take the time to understand the very basic facts of what is being proposed here.
Re: (Score:2)
See, this is what I'm talking about.
You see it's a bit like robbing a bank and being upset that people are not interested in intimate details of your excuse opting instead to call you a bank robber to your face without having first carefully studied your manifesto.
You don't even know what he's arguing, and your point about "data related to their developers" is completely irrelevant because that's not what is being suggested at all.
At least take the time to understand the very basic facts of what is being proposed here.
In addition to above I did take a few seconds to look before posting. It seemed to roughly be about collecting counters for certain calls at granularity of once a week or so.
If you do something like that the collector gets the IP of the sender along with usage data that can be used
Funny because it's true (Score:1)
How to alienate your software community - 101
Funny because it's so true. But really, go has been doing this for years.
I used to make wide use of a project called syncthing [syncthing.net], and it is, I think, a good indicator of go's problems. Syncthing is a peer-to-peer file transfer/synchronization program written in go. On the surface it looks really good, until you try and implement it. Because:
1) Right off the mark you have to come up with your own way to daemonize it. It's a service that can't fork itself into the background. So every user has to come up w
Audacity (Score:1)
Does nobody remember the fiasco when Audacity proposed the same thing?
Re: (Score:2)
These alarmed developers would prefer an opt-in rather than an opt-out regime, a position the Go team rejects because it would ensure low adoption and would reduce the amount of telemetry data received to the point it would be of little value.
And people said that the Go team did not understand the position of the development community.
Don't Trust Free Things From Google (Score:5, Insightful)
'nough said.
Re: (Score:1)
Google would telemetryze & spam their own grandmothers.
Re: (Score:3)
stick a fork in GO, it's done (Score:4, Insightful)
that a language lead would even consider such a thing a pretty good idea means the project is run by those with no common sense whatsoever.
Re: (Score:3)
that a language lead would even consider such a thing a pretty good idea means the project is run by those with no common sense whatsoever.
Never trust anyone to be honest when their paycheque depends on them being lying ass-wipes (I'm paraphrasing here, but you get the idea).
Re: stick a fork in GO, it's done (Score:1, Insightful)
What are you talking about? I don't understand where all this hate is coming from.. they proposed a change to an open source toolchain. They openly describe what they want.. if it is implemented you can literally see exactly how it works... How can you say because of those actions they are not honest people?
It's not like they want to exploit some technically illiterate end users to spy on their every action.. it's literally developers who can be expected to know how things work and could even look exactly a
Re: stick a fork in GO, it's done (Score:4, Insightful)
Making spying on users the default is a BS techbro move. The dev defending it is thinking with his job security, not his head.
And he's already said why they want it to be the default - if users had to opt in, almost nobody would. So fuck him, just like he wanted to fuck over users.
Re: (Score:1)
It is, but they aren't proposing spying on anyone. All they want to do is gather some basic stats on the use and performance of certain language features, so they can see where to put effort in for maximum returns and developer benefit.
Re: (Score:2)
Re:stick a fork in GO, it's done (Score:5, Insightful)
It's Google. Their business basically consists of raping your privacy. They gave you a programming language for free, waited for adoption levels to be sufficient that a lot of people can't easily back out anymore without having to rewrite a lot of code, then start to add the privacy raping part.
If you look down the line of Google products, you will find this pattern. Any halfway successful Google product follows it. The Google graveyard is filled with products that either failed to reach an adoption level where the potential data mined doesn't warrant the adding of the privacy raping part or that turned out that they couldn't sensibly be data mined. Every single Google product has this "feature".
The ones that don't are still trying to reach a market saturation where it becomes viable. If they can't get there -> Google Graveyard.
Re: stick a fork in GO, it's done (Score:2)
Re: (Score:2)
Why? It's actually quote common already.
For example, Visual Studio Code is the most popular IDE by far, and it's got a lot of telemetry in it.
There are projects that scan thousands of open source repositories to gain insight into how languages are used. Many open source apps include telemetry to help the developers identify and debug problems.
While I agree that making it opt-out is the wrong decision, the basic idea of collecting some non-identifying and very general statistics, and making them public so ev
Re: (Score:1)
Others doing evil thing doesn't make an evil thing good.
Spying on people and eating up their bandwidth is wrong.
You don't know right from wrong. Very telling you use Visual Studio as example, a tool for writing Windows garbage, Window the infrastructure that spies on people, is unreliable and attacks malware like manure brings flies.
Stay in your containment zone, Microsoft shill. Anyone with a brain wants nothing you have to offer.
Re: (Score:2)
Again, TFA notes that the bandwidth "eaten up" would be a few kilobytes a year at most.
I see you don't know what Visual Studio Code is either. The reason it's so popular is that it's cross platform and big with Linux and web developers. It's actually kinda weak for doing Windows development, lacking a lot of the stuff that Visual Studio has.
This is why we should discuss this. Most of the comments are like yours - ignorant.
Re: (Score:1)
I see you don't know what Visual Studio Code is either, it's advertised with the lie of being free and open source yet requires accepting proprietary closed licenses to download and use.
Another Microsoft trap.
There is no discussion possible with the evil and ignorant such as yourself. Educate your ignorant self.
So safe. (Score:5, Funny)
It's safe, because that's the way it's designed. And we know that "designed to be safe" automatically means something is safe. And we know that if something is designed to work a certain way, then it's okay. Don't question the design itself, because it's okay as long as it supposedly works according to its design.
We should all flock to any language that calls itself safe because there's nothing more trustworthy than something that says it's trustworthy.
Re: (Score:2)
Omg. Its what you say when. .. (Score:2)
The cookies are bad for you. So I'm going to save you from yourself by doing EVERYTHING. You do NOTHING. You cant get a better deal than that. You'd actually be crazy to NOT agree.
Amirite?
I think they should do it (Score:2)
Since I don't use Go, I am all in favor of baking this into a language and see what the end result really is like. Do programmers really move away from it? Or will a large number decide they benefit from the tracking and want it left in, because they would have added analytics anyway?
Not every language has to be the same... the more variety the better.
Re: (Score:2)
Ponder this: You invested a nontrivial amount of time learning a language. Do you now drop it because of that change?
Either you don't know about it, then you don't know about it. Or you do know about it and disable the whole telemetry bull. Either way, this won't affect the number of people using it. Aside of maybe the handful purists who will now oppose it on principle.
If the article asks a question, the answer is "No" (Score:3)
It was a draft proposal, to see if it was sane. The answer was, of course, "No"
To be precise, "No, change it to opt-in. That's sane".
This made up my mind (Score:1)
Re: This made up my mind (Score:2)
Adoption of opt-in doesn't have to be low (Score:2)
Problem is, you have to make your case why opting in benefits the end user or the language as a whole.
Note that "because Google would really like the data" is not a good example of making an effective case for opting in.
Re: (Score:3)
If Opt-in results in low adoption, most of the time it means that there's no benefit in it for the user or it's even detrimental to the user's interests.
Don't use advertising agency software handouts (Score:4, Insightful)
I've long warned about using products from Google and Facebook because they have no interest in your success. My prior concern is that both are known for breaking backwards compatibility willy nilly...think Google's Angular nightmare. I was burnt heavily by Google's Puppeteer changing all their APIs for some reason. Google doesn't care if your old code works...but I bet your employer does and doesn't want to spend hundreds of thousands of dollars to rewrite perfectly good software every time some Googler gets bored and wants to break all their APIs
For all of it's unsexiness, J2EE code written 20 years ago still runs on the latest versions of the servers. (should you be running 20 year old EJBs?...well, for your sake, I hope you're not...but that's how seriously the Java EE maintainers take your business needs) .
My first Java programs written in 1996, back when I was learning from a giant hernia-inducing 5lb hardcover book with a 3" spine still run on Java 19...no change needed..they can also be recompiled with the latest version, no changes needed. Why? Because Sun Microsystems, like Microsoft, is in the business of selling professional software tools...not selling my data. It was designed for long-term investment and complex business logic that is complicated and really important to get right, not a quick prototype that gets major rewrites every 2 years .
Ask the pain of anyone who used the first version of Angular. You're getting a handout from a company who earns no money from you and has no interest in your project succeeding...it rarely matters in the first 3 years, but if you build something worth keeping that actually makes money, maintenance becomes an issue. What happens when your company's investment is 10 years old? What happens when you leave or get promoted or change roles? When you think about things from the perspective of those paying your salary, you really need to carefully consider these factors and Google and Facebook are notorious abusers of them.
I know a division in my company wrote security-sensitive code in Go. Now they have to carefully ensure all their code isn't leaking sensitive data to Google. All these years, I've been warning them about Google accidentally breaking something out of carelessness...not doing something that jeopardizes their operations and security compliance certification on purpose...and pretending its for the benefit of the open source community.
Illegal in the EU (Score:4, Interesting)
Collection of any data that is tied to people (and storing an IP is enough for that) needs to be default-off. By law.
But I welcome that they try this. Now I can permanently remove Go from the list of tech I intended to look at.
Re: (Score:2)
But they aren't collecting any data that can be tied to people, or IP addresses. So by your own logic, there is no reason to not use Go.
It's frightening how easy you are to manipulate with FUD. One Slashdot story, and they can be sure you won't RTFA, and the technology is dead to you. I've noticed this happens quite a lot of Slashdot. Very easy to use against your competitors.
Wow. Just. Wow. (Score:3)
Networking isn't even a part of the C standard library, let alone the language and Google wants fucking TELEMETRY in Go, which I'm given to understand is supposed to be a systems language???
You know, Rust is by no means the ideal language; but if you want to use something like "telemetry" to improve the project, they've got the right idea. The Rust team routinely pulls Rust code from F/OSS repositories, compiles it, and checks for anything that might be a problem with Rust. This, by definition, is opt-in since you've already put your source on a public repository under licenses that don't restrict the field of endeavor.
Night and day. Based on this alone, I'd chose Rust over Go if those were the only options.
Re: Wow. Just. Wow. (Score:1)
I get it... (Score:2)
But there has to be a better way to handle this. I've
Re:I get it... (Score:4, Insightful)
The problem with the whole telemetry-to-improve-user-experience thing is that there is no reason to trust Google any further than I can throw their board members.
If a reputable company that doesn't have a track record of raping people's privacy asked, this may be a completely different matter. But this is akin to a convicted pedo applying as a babysitter. It's simply common sense to say NO.
Yup. (Score:2)
It feels nice being right, but in this instance, wish I wasn't. Adding another reason to my list.
May? (Score:2)
May? ...Pssshh.
And everybody knows it.
Goodgo? (Score:2)
May be it's time for go to go.
Take the hint, Google (Score:4, Insightful)
If "Opt out" results in a low adoption, chances are good that the only reason people leave it active is because they don't know that it exists. Because if it's Opt-In and you really want people to use it, and they don't outright oppose it, you could simply ask them to turn it on, advertise it and try to sell it as the best thing since sliced bread.
But yeah, I can see how "do you want us to spy on you?" is a really hard sell.
Just like every other programming language (Score:2)
Does *any* other programming language have telemetry baked in?
For the others, how can they possibly improve?
They have spying in their DNA (Score:2)
That's the only explanation I can give for seeing them *getting offended* at people requesting not to be spied without consent.
6 of one 1/2 dozen of the other (Score:2)
A subterfuge to improve Bard? (Score:2)
.
Attempts to make a language profitable (Score:1)
Beware: Paranoia fungus (Score:2)
Judging by the tone of many of the comments.
Just a wee note: You are free to use duckduckgo. No one is forcing you to search with google.
You are free to use a privacy-enhanced browser with do not track defaults and a proxy for good measure too.
If only your life was important enough for anyone to give a shit about tracking you in particular.
That's something you should aspire to.