cmd/go: telemetry data should not be in $XDG_CONFIG_HOME

[AGWA]

Go version

go version go1.23.0 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/andrew/.cache/go-build'
GOENV='/home/andrew/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS='-modcacherw'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/andrew/.go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/andrew/.go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/golang/go1.23.0'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/golang/go1.23.0/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='off'
GOTELEMETRYDIR='/home/andrew/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='0'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2289507740=/tmp/go-build -gno-record-gcc-switches'

What did you do?

1. Upgrade to Go 1.23.0
2. Use Go for several days

What did you see happen?

My $XDG_CONFIG_HOME/go/telemetry directory ($HOME/.config/go/telemetry) is now full of data files, in violation of the XDG Base Directory Specification which reserves $XDG_CONFIG_HOME for configuration.

What did you expect to see?

I expected telemetry data to be stored in $XDG_STATE_HOME instead.

[gabyhelp]

Related Issues and Documentation

• cmd/go: GOTELEMETRY is not documented by go help environment #68928

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @golang/telemetry

[findleyr]

Thanks. My understanding is that os.UserConfigDir was chosen for its portability, and to consolidate all the telemetry data in one place. However, we may be able to use more appropriate directories on POSIX systems.

For the record the rationale for choosing $XDG_STATE_HOME over $XDG_DATA_HOME is that this data is not portable, and relates to specific application state? If so, it may be that $XDG_STATE_HOME is most appropriate for counter files and logs, and $XDG_DATA_HOME is most appropriate for consolidated the weekly JSON summaries (local or uploaded reports).

[AGWA]

$XDG_STATE_HOME is for application state, whereas $XDG_DATA_HOME is intended for things like font or icon files (the sort of stuff that is found in /usr/share), though many applications put state there because $XDG_STATE_HOME didn't always exist. So all telemetry data, including the weekly JSON summaries, belong in $XDG_STATE_HOME.

See https://lists.freedesktop.org/archives/xdg/2016-December/013803.html, https://wiki.debian.org/XDGBaseDirectorySpecification, and https://www.reddit.com/r/linux/comments/ny34vs/new_xdg_state_home_in_xdg_base_directory_spec/ for background.

[findleyr]

Notes from our meeting discussion of this issue:

• Someone pointed out that XDG_STATE_HOME is relatively recent, in 0.8 of the spec from 2021. As a result it may not have been considered in the original design.
• Unfortunately, it seems we are not the only offenders here. Searching my ~/.config finds plenty of data files for various applications. Nevertheless, we'd like to be good citizens if possible.
• Changing this now would be nontrivially disruptive. For example, all our documentation and historical discussion about telemetry data become stale, as does go env GOTELEMETRYDIR.
• There is advantage to being able to reference os.UserConfigDir as the definition of where data is stored. The complexity of having a more complicated heuristic could harm the clarity of our documentation.
• Cursory investigation indicates that no analog exists on Mac or Windows. (e.g. this Rust library).
• We're not yet sure whether it is desirable to separate data which is more naturally configuration (e.g. the mode or weekends file) from data which is stateful (counters and reports). It may actually be cleaner to have state in a separate directory, as then the clean operation becomes trivial.

So, my current sense is that while XDG_STATE_HOME may be the more appropriate directory on Linux, it's not clear whether the upside of making this change now offsets the downside. If there were something like os.UserStateDir, that downside would be significantly reduced, but does such an API make sense if there aren't good analogs on Windows (or even Mac?).