Hacker News Reader

Comment by saagarjha | Hacker News Reader

IMO the only part of this article that is general enough to discuss is the bit about opt-out telemetry; everything else is just slapping technical solutions and attempts at preserving privacy on top of an opt-out system.

On that front, I find it confusing why the option of “we ask the user when they install what they want” is not explored. It’s given as an example in the article, and then there’s a whole section about how they want to give people sufficient notice on their website and how it would be bad to report stats before people could realize it’s turned on. Why not just tell them when they install and let them change it then and there?

View on HN

> I find it confusing why the option of “we ask the user when they install what they want” is not explored.

I don't. It's because they know that most people don't want this, and will say no if asked, but won't realize they need to opt out if it's just silently enabled by default.

Most users don’t want to send telemetry. But most users also want a system built by people who understand how users use it.

You can achieve 99% of that by using your own product and talking to your customers, and everybody managed to do just that and to make useful products long before telemetry became ubiquitous.

People don’t know how many cache misses they had, or what IO exceptions and retries led to their poor experience. They know they had a poor experience.

No one will afford to make interviews on the scale of making good statistics.

Knowing when I can sunset support for a specific OS or hardware (e.g screen resolution) would require a huge amount of expensive surveying.

The telemetry that tells me 20% of my users use 4K screens now literally costs single digit dollars per month. It costs the same as one or a handful of “talking to users”. More importantly, you don’t need to waste precious time when talking to users with asking them what driver version or screen resolution they have. Because of course users are spoken to. Telemetry isn’t instead of talking to users. It’s so that a) you can focus your user conversion on human focused things and b) so that you cover a wider group than you could ever afford talking to.

It’s better to be up front with the fact that software does anonymous telemetry and prudent that it actually is good (anonymous, and not using excessive resources).

I would argue that using your own product and talking to your customers is the only way to make good and useful products. Telemetry may have a good use case (although I struggle to find one), but it isn't a substitute for dogfooding and direct customer interaction.

The true use case here is to get you used to the idea of telemetry in your tool chain, then move the goal post further down the road. In a few years, it'll be encouraged to put telemetry in your library ("Why?" "We've already had it in the tool chain this isn't any different!") then eventually, have every application sending telemetry data to Google's servers.

If you think this is ridiculous, remember they built Chrome with telemetry embedded .. why? Not for improving services. To build better targeted advertising.

Remember Android OS? Yes.

But there's still push back and the primary group of people resisting this at large are developers and the more technically inclined.

> why the option of “we ask the user when they install what they want” is not explored.

Because Go == Google, and when has Google "asked the user" before slurping data?

If they are going to do it, it should only ever be on an OPT-IN basis.

This is very uninteresting data to Google. They are interested in personal data that you can use to optimize targeted ads, not compiler cache miss counts from your local development workflow.

The reasoning for not making this opt-in are in the blog post and I find them reasonable.

Their reasons are centered on the low returns of opt-in (due to people regularly not changing defaults). They obviously fail to see that people might check their settings and do not want to opt in. And the reason for that is given right after that observation: people have been burned too often by companies and systems that slurp up ever more data way beyond what is necessary for the alleged purpose.

Opt-Out is simply not acceptable.

If you think this data is not interesting to Google, I think you're not using your imagination enough. Even "compiler cache miss counts from your local development workflow" could be used as a signal to optimize ads for development tooling. Or hardware.

In general, when looking at telemetry data, you can't stop at asking "what possible use would the org collecting it have for it right now, in their current business model". You need to also ask what use they could potentially have for it in the future, especially combined with other data they have access to. A year from now, or five years from now, or after a pivot, or after partnering with (or buying) a company in a different industry, or after leaking (or selling) it to third parties.

When you ask these questions, I think you'll also conclude that enabling telemetry by default and pinky swears they're not doing anything naughy with it is not good enough. You may trust the people doing it now, but as experience shows, business priorities change, people in charge change, but the collected data remains.

A set of static, anonymous metrics, updated _once_ a year from a tiny fraction of developers is not worth the effort to even ingest into some targeting system.

There's many ways to get valuable data for ad targeting, this is not one of them.

If they want to turn bad, they can just use the dependency proxy.golang.org / sum.golang.org that already exist for a long time. Or gather data on things running in Google Cloud. All of these would be unlikely, and bigger levers than gathering some data from a few Go developers.

There are many other applications for data than just ad targeting.

The pushback here may seem paranoid for the specifics of this particular case, but that's because it comes from a more generic and IMHO perfectly justified position of treating all telemetry as risky by default, and all attempts at making it opt-out as wrong, dangerous, and likely malicious.

The arguments "for" are all based on assertions about this particular case at this particular point in time. The data to be collected is benign. Collecting it will translate to meaningful improvements being delivered faster. The people behind the project are all nice and reputable. And so on. In contrast, the arguments "against" cover the possible future evolution of the telemetry itself, as well as the project and the people behind it. The set of metrics and reporting frequency can change. The goals behind it can change. The nice people might turn naughty, or be replaced by scoundrels.

The arguments "against" include, in particular, building the precedent and infrastructure. From that point of view, you saying:

> set of static, anonymous metrics, updated _once_ a year from a tiny fraction of developers is not worth the effort to even ingest into some targeting system

sounds to me like me saying "this browser extension, which code I audited myself, is only reading the account numbers and names from my banking page - it's really not worth anyone's effort to do anything naughty with it, so there's no reason I should be afraid of giving it full read and write permissions for the banking page, and no reason I shouldn't leave the 'auto-update' checkbox on".

> This is very uninteresting data to Google.

It's not about how interesting the data is to them, it's about the hubris of believing they are entitled to every last bit of our data.

Let's not forget the https://en.wikipedia.org/wiki/Boiling_frog

> If they are going to do it, it should only ever be on an OPT-IN basis.

They made their case against it, and I can even understand the reasoning behind it. Doesn't mean I have to agree though.

But still there's programs like Git as an existing example of this kind of "ask the user" thing. Last time I checked:

* When you run `git init` without having configured default branch name it warns you with a big wall of text.

* When you run `git commit` without having configured a user, it warns you with a big wall of text.

* When you run `git pull` without having configured the strategy, it warns you with a big wall of text.

As much as I want to give them the benefit of doubt, this really comes off as wanting to silently enable it by default, because they know that if they actually ask in a similar way that `git` does, the answer will be "no".

As much as I like and appreciate git, it's hardly a good example for something with great UX.

Exactly, it's an example of a CLI that already messed up its interface, and has actually changed commands (checkout -> switch, has added flags for submodules, etc), and overall has improved since past versions, and still tries to improve.

And AFAIK it didn't add telemetry to send used commands to any server, even if that would have been by far the easiest way, given 90% of devs use it and complain about how bad it is.

It's an arbitrary percentage, but it gets the point across. The amount of devs using git is probably at least an order or magnitude higher than those using Go.

Go, on the other hand, already has decent-ish tooling (at least better Git), but it wants to add opt-out telemetry anyway.

Reply on news.ycombinator.com