Enabled by default can and should be the default for security-related features.
I tend to agree about the rest of the creepiness, especially anything personally behavioral.
If you want to know which Go modules I use, go check out my github. They're listed right there in import statements. If I'm hacking on a project that I want to keep private, I'll disable this feature with a command line flag - easy.
My issue with the paranoid folks in that thread is not that they made no sense (they can't help that), it was they were attacking the person who implemented the feature viciously. He had implemented a feature that a majority of Go developers had been requesting for 5+ years, had done it in a way that improved clean build time, improved security and could easily be disabled or replaced with a private DB. Literally what else could that man have done?
Even though all his work could be verified trivially (Go is open source!), they still chose to attack him.
He could have not sent all build-time network accesses to Google by default. It's that simple.
Why are you so upset that other people will be using a feature you obviously won't? Why are you upset when this leaks literally no info that your github repo doesn't already?
I bet the DB is small enough that you could default to just downloading it and syncing on your machine.
Care to maybe check real quick before making bets?
This makes sense right? Cargo, the rust package manager, does replicate the entire package index using git and it is ~250 MiB (~150MiB in .git/) (The cargo index stores much more metadata in a more verbose JSON format). It seems like a very reasonable bet considering prior art.
That's a conservative estimate, and if you try to sync only what's needed you're no better off then not-syncing.
If you try syncing the whole thing incrementally (rsync style) all you leak is the frequency of your updates
I get that Google changed the way go packages work, but I don't understand the difference between that and literally every package manager in existence.
Try being a little less rude to the other folks on this thread.
Sound decision making requires metrics. If you opt-out of metrics, you don't get to participate in decisions.
Not use data from a mechanism that's controversial with some of the user base to drive decisions? Reach out and ask people, instead of asking their machines?
> Sound decision making requires metrics. If you opt-out of metrics, you don't get to participate in decisions.
Sound decision making requires some kind of metrics and also sound reasoning. It doesn't mean that metrics have to be widely-deployed telemetry. There are alternatives, like doing studies "the old way". Moreover, it can be argued that a lot of problems on today's Internet stem from people vacuuming up whatever data they can find and divining decisions out of it. It's not how you do science.
That would require more time and money that could be spent elsewhere.
So you would have statistics biased by not accounting for people not bothered to answering these questions instead of not accounting for people not using popcon?
Would you agree to a Democracy where the government put sensors in your house, then told you which candidate your vote would be counted towards from your behaviour?
And if you opted out of that, you don't get to participate at all?
"If you deal with people with strict security/privacy requirement, you are correct to do so. I would do the same."
Not since Google uses the argument of increased security to justify data collection for quite some time in the interest of itself.
If you're in the minority, you should expect to have to do more work to get the right balance of security and privacy.
> If you're in the minority, you should expect to have to do more work to get the right balance of security and privacy.
It is exactly this false dichotomy that I am criticizing here, because it is completely baseless.
You are reading an article that hints to privacy violations.
You can only be secure if your privacy is protected. That is the causal relation between these two needs.
This isn't a veneer. It's a signature check to ensure a package is what it says it is. Have you seen the hassle npm routinely goes through because of this? A centralized, trusted server is a sensible "default" setting. The fact that they offer a self-hosted solution is a great benefit.
> You can only be secure if your privacy is protected. That is the causal relation between these two needs.
Nonsense. I can have a completely secure system and everyone knows who I am. I can have an entire insecure system with zero means of identifying the owner and thus, remain private.
You aren't just conflating privacy and security, you are implying a casual relationship between them. Both are nonsense.
How do you figure?