4 ms·

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future. The idea that the lang

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future. The idea that the language I'm programming in now reports anything back to google is distressing.. and I say that as someone who has been programming in Go for about 7 years. What right does google have to collect usage information from modules hosted on github (or elsewhere)? I checkout the code for the modules, review it, and commit it into my own repository. I don't need you to speed up the rare git checkout of a module. Not that I think some minor speed improvement is worth my privacy. You talk about decentralization... while centralizing the entire thing around Google. You talk about git.apache.org being down, while you're willing to bring down the entire ecosystem across the board with your own special server. This "feature" should have an option to disable it.. at the very least. This is the first language in my 23 years programming that reports my usage back to the language authors. It's unprecedented. And the truth is, if this is ok to you, then there's really no limit what the code I write today, may report back to google tomorrow.

TheDong 7y ago
> This is the first language in my 23 years programming that reports my usage back to the language authors I suppose that means you haven't used any of: 1. nodejs, which reports your usage back to npm Inc with the exact same amount of detail (names of dependencies, ip of caller) (and stores much more, since it publishes 'downloads per month', etc) 2. rust, which does the same with crates.io 3. perl, which does that with cpan 4. python, which does that with pypi 5. ... etc All of those languages have a central registry of packages that has the same level of detail in the metadata it can potentially collect as the go proxy does. > This "feature" should have an option to disable it.. at the very least. It does. Multiple options. You can run your own proxy, disable it entirely, or opt out of the go mod experiment and never run go get, but rather vendor by hand with `git clone` or whatever. > And the truth is, if this is ok to you, then there's really no limit what the code I write today, may report back to google tomorrow. Very much a slippery slope. They've communicated clearly how to disable it and what it does, it's in-line with what other language ecosystems do in terms of metadata reported to a central package repository, and I think it's very easy for someone to be okay with this, but to not be okay with any step beyond this line.
- mfer 7y ago
  There is a difference between npm, perl, and the others mentioned and Go. Go is Google with a diverse set of products and services. Many people who use Go build competitive services to Google. What company is using python and building something in competition to the python software foundation? Or something for the others? This difference is worth taking into account. If Go were part of a software foundation like Python this would be a different story.
  - dragonwriter 7y ago
    So, the issue isn't the information sent back to the language maintainer, but the identity of the maintainer?
- rgbrenner 7y ago
  If I download something from a server, of course that server knows what I downloaded. This is different. It’s a proxy in front of others repositories. They want info on downloads from GitHub, gitlab, and anywhere else you get code from. They (google) are a 3rd party to the download.
  - TheDong 7y ago
    > This is different. It’s a proxy in front of others repositories It's not all that different. It's perfectly possible to use gems in ruby without ever using the rubygems server by setting every gem to be something like 'gem foo, :source = "https://github.com/foo/bar"' https://github.com/foo/bar"' However, people want to use this centralized repository in the ruby community because it allows for easily updating gems and for convenient caching. The go proxy is not just a proxy. It also pre-parses out go.mod/go.sum to provide metadata faster and to provide security guarantees. In a similar way to how centralized repositories are helpful in other languages, the go proxy adds actual legitimate features. If you look at the public information on its development of this feature, all the motivations cited are about security, performance, and useful features, not information collection. > This is different There is a difference. Other repositories, like npm, require someone to opt-in to code being available via it (e.g. type `npm publish`, whether the publisher owns the package or not), while the go proxy default opts-in everyone that publishes a go package publicly and uses the newer go toolchain. In practice, with how the npm/rubygems/etc communities work, everyone does opt-in if they wish their code to be publicly used, so the difference doesn't seem meaningful to me. Other than that, the difference seems vanishingly small. In both cases, a 3rd party exists that serves downloads, and it exists to provide performance and discoverability benefits (with the go proxy also does due to supporting version-related operations), and in some cases security benefits.
Zancarius 7y ago
> This "feature" should have an option to disable it.. at the very least. You should be able to. It's not the ideal solution (or recommended for most use cases), but you can by setting GOPROXY=off. GOPROXY=direct will force it into its previous behavior. The same should be true for the checksum DB with GOSUMDB=off. I don't remember specifically and can't find the page its options were documented on. Also look at GOPRIVATE and GONOSUMBDB.
- deleted 7y ago
  [deleted]
- cesarb 7y ago
  IMO, using an environment variable for that is not robust. If the environment variables have been cleared (for instance, due to "su -" or similar), or if they have never been set (for instance, because you just checked out the code on a new machine and forgot to configure the environment variables there, or because you did remember to configure the environment variables but forgot that startup scripts do not take effect on an already running shell), the defaults will apply. Using a configuration file within the source directory would have been more robust.
  - shkkmo 7y ago
    You can use a shell script that you check into your repos that explicitly sets these environment values instead of using the go command directly. As long as you habitually never run "go get" or "go build" directly it ameliorates the issues you mentioned.
    - Cthulhu_ 7y ago
      Indeed; if you're working with multiple developers and you need these policies enforced, you should use e.g. a makefile. I'm not sure if it's possible to force the use of that over straight `go` commands though.
  - Zancarius 7y ago
    I agree. I don't like the solution either, but it is what it is. What worries me is that if the envvars aren't set, there's a potential for leaking information. But, it's still possible to disable these features, so it's not quite as bad as the OP suggested.
zeeboo 7y ago
> You talk about git.apache.org being down, while you're willing to bring down the entire ecosystem across the board with your own special server. If the proxy goes down, by default the command falls back to directly fetching.
- typical182 7y ago
  You can also pick your own proxy primary and fallbacks. For example, this should in theory work to make the google-run proxy your fourth choice, with three other proxies attempted before the google-run proxy, and with direct (no proxy) access as the fifth and final fallback: go env -w GOPROXY=gocenter.io,goproxy.io,goproxy.cn,proxy.golang.org,direct There is some geographic diversity in that example as well -- I think two mirrors in that list are primarily run in China.
typical182 7y ago
> This "feature" should have an option to disable it.. at the very least. The Go 1.13 Release Notes lead off with documentation links for how to disable and otherwise configure this: "See https://proxy.golang.org/privacy https://proxy.golang.org/privacy for privacy information about these services and the go command documentation[1] for configuration details including how to disable the use of these servers or use different ones. If you depend on non-public modules, see the documentation for configuring your environment[2]." [1] https://golang.org/cmd/go/#hdr-Module_downloading_and_verification https://golang.org/cmd/go/#hdr-Module_downloading_and_verifi... [2] https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules https://golang.org/cmd/go/#hdr-Module_configuration_for_non_...
icholy 7y ago
Maybe try reading the release notes before ranting non-sense.

TheDong 7y ago

> This is the first language in my 23 years programming that reports my usage back to the language authors I suppose that means you haven't used any of: 1. nodejs, which reports your usage back to npm Inc with the exact same amount of detail (names of dependencies, ip of caller) (and stores much more, since it publishes 'downloads per month', etc) 2. rust, which does the same with crates.io 3. perl, which does that with cpan 4. python, which does that with pypi 5. ... etc All of those languages have a central registry of packages that has the same level of detail in the metadata it can potentially collect as the go proxy does. > This "feature" should have an option to disable it.. at the very least. It does. Multiple options. You can run your own proxy, disable it entirely, or opt out of the go mod experiment and never run go get, but rather vendor by hand with `git clone` or whatever. > And the truth is, if this is ok to you, then there's really no limit what the code I write today, may report back to google tomorrow. Very much a slippery slope. They've communicated clearly how to disable it and what it does, it's in-line with what other language ecosystems do in terms of metadata reported to a central package repository, and I think it's very easy for someone to be okay with this, but to not be okay with any step beyond this line.

mfer 7y ago
There is a difference between npm, perl, and the others mentioned and Go. Go is Google with a diverse set of products and services. Many people who use Go build competitive services to Google. What company is using python and building something in competition to the python software foundation? Or something for the others? This difference is worth taking into account. If Go were part of a software foundation like Python this would be a different story.
- dragonwriter 7y ago
  So, the issue isn't the information sent back to the language maintainer, but the identity of the maintainer?
rgbrenner 7y ago
If I download something from a server, of course that server knows what I downloaded. This is different. It’s a proxy in front of others repositories. They want info on downloads from GitHub, gitlab, and anywhere else you get code from. They (google) are a 3rd party to the download.
- TheDong 7y ago
  > This is different. It’s a proxy in front of others repositories It's not all that different. It's perfectly possible to use gems in ruby without ever using the rubygems server by setting every gem to be something like 'gem foo, :source = "https://github.com/foo/bar"' https://github.com/foo/bar"' However, people want to use this centralized repository in the ruby community because it allows for easily updating gems and for convenient caching. The go proxy is not just a proxy. It also pre-parses out go.mod/go.sum to provide metadata faster and to provide security guarantees. In a similar way to how centralized repositories are helpful in other languages, the go proxy adds actual legitimate features. If you look at the public information on its development of this feature, all the motivations cited are about security, performance, and useful features, not information collection. > This is different There is a difference. Other repositories, like npm, require someone to opt-in to code being available via it (e.g. type `npm publish`, whether the publisher owns the package or not), while the go proxy default opts-in everyone that publishes a go package publicly and uses the newer go toolchain. In practice, with how the npm/rubygems/etc communities work, everyone does opt-in if they wish their code to be publicly used, so the difference doesn't seem meaningful to me. Other than that, the difference seems vanishingly small. In both cases, a 3rd party exists that serves downloads, and it exists to provide performance and discoverability benefits (with the go proxy also does due to supporting version-related operations), and in some cases security benefits.

Zancarius 7y ago

> This "feature" should have an option to disable it.. at the very least. You should be able to. It's not the ideal solution (or recommended for most use cases), but you can by setting GOPROXY=off. GOPROXY=direct will force it into its previous behavior. The same should be true for the checksum DB with GOSUMDB=off. I don't remember specifically and can't find the page its options were documented on. Also look at GOPRIVATE and GONOSUMBDB.

deleted 7y ago
[deleted]
cesarb 7y ago
IMO, using an environment variable for that is not robust. If the environment variables have been cleared (for instance, due to "su -" or similar), or if they have never been set (for instance, because you just checked out the code on a new machine and forgot to configure the environment variables there, or because you did remember to configure the environment variables but forgot that startup scripts do not take effect on an already running shell), the defaults will apply. Using a configuration file within the source directory would have been more robust.
- shkkmo 7y ago
  You can use a shell script that you check into your repos that explicitly sets these environment values instead of using the go command directly. As long as you habitually never run "go get" or "go build" directly it ameliorates the issues you mentioned.
  - Cthulhu_ 7y ago
    Indeed; if you're working with multiple developers and you need these policies enforced, you should use e.g. a makefile. I'm not sure if it's possible to force the use of that over straight `go` commands though.
- Zancarius 7y ago
  I agree. I don't like the solution either, but it is what it is. What worries me is that if the envvars aren't set, there's a potential for leaking information. But, it's still possible to disable these features, so it's not quite as bad as the OP suggested.

zeeboo 7y ago

> You talk about git.apache.org being down, while you're willing to bring down the entire ecosystem across the board with your own special server. If the proxy goes down, by default the command falls back to directly fetching.

typical182 7y ago
You can also pick your own proxy primary and fallbacks. For example, this should in theory work to make the google-run proxy your fourth choice, with three other proxies attempted before the google-run proxy, and with direct (no proxy) access as the fifth and final fallback: go env -w GOPROXY=gocenter.io,goproxy.io,goproxy.cn,proxy.golang.org,direct There is some geographic diversity in that example as well -- I think two mirrors in that list are primarily run in China.

typical182 7y ago

> This "feature" should have an option to disable it.. at the very least. The Go 1.13 Release Notes lead off with documentation links for how to disable and otherwise configure this: "See https://proxy.golang.org/privacy https://proxy.golang.org/privacy for privacy information about these services and the go command documentation[1] for configuration details including how to disable the use of these servers or use different ones. If you depend on non-public modules, see the documentation for configuring your environment[2]." [1] https://golang.org/cmd/go/#hdr-Module_downloading_and_verification https://golang.org/cmd/go/#hdr-Module_downloading_and_verifi... [2] https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules https://golang.org/cmd/go/#hdr-Module_configuration_for_non_...

icholy 7y ago

Maybe try reading the release notes before ranting non-sense.