Hacker News Reader

Comment by cube2222 | Hacker News Reader

Probably related to[0].

To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually.

The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You don't really get any kind of sensible sample if you only do it opt-in. Additionally, this ship has long sailed, everybody does opt-out.

What I do think however, is that it should very clearly notify the user of this, and give them an easy way to disable it. Like in OctoSQL[1] (disclaimer: which I'm the author of) which prompts you on first run and shows explicitly how to disable it.

All things considered, this is an open source project, so you're free to maintain a fork without telemetry. The Go toolchain also uses the Google-hosted module proxy by default, which really is a bit like telemetry already.

[0]: https://news.ycombinator.com/item?id=34707583

[1]: https://asciinema.org/a/eWQsyXQKi1fmithyTekAD5fWS

View on HN

The argument for this being opt-in isn't about "it works better", it is about it being ethically correct. There are a ton of things that "don't work" unless you do something unethical: that doesn't mean they are OK, it doesn't mean they should be tolerated, and it doesn't mean the people who do them--and, at the end of the day, it is people who make these decisions: there is a human being who refused to say "no" and whose name we might even be able to find out--shouldn't be judged by their peers for doing these things... and that is all true even if it is (currently) legal for them to do it!!

You're framing this as though the "ethical" choice were obvious, or that there was a person who "knew this was the ethical thing to do, but turned a blind eye".

I disagree, I think it's a very contested topic, with lots of discussion whenever it's raised here, with either side possibly being a vocal minority.

The ethical choice is obvious.

The distinction is between "What I do with my computer is none of your business unless I choose to make it your business" versus "What I do with my computer is your business unless I choose to not make it your business".

It's insane that we are still having to justify privacy as a default, or that people continue to rationalize away the concerns.

Yeah, maybe if it's opt-in they won't have much telemetry data. Perhaps, in fact, it would not be much better than having no data at all. That will make some things harder. Major bummer. If it was easy to do the right thing, more companies would do it.

> It's insane that we are still having to justify privacy as a default

Half of the HN is in love with Chrome and nearly all are on Gmail.

The relentless drive towards the erosion of privacy powered by free carrots worked.

There is now a whole generation of people that sees all this as a norm.

Any program is opt-in, so you just don't have to use it. Mayor bummer. Assuming data collection is properly disclosed, ofc, but i don't see anyone here arguing against that.

The "there shouldn't be any" argument just seems so entitled with there being such demand / reasons to do so. I applaud everyone trying to find ways to satisfy both sides, as done by the original article.

You can't satisfy both sides by completely ignoring one side.

"What I do on my machine is none of your business, unless I decide it's your business" is a strong argument, presented multiple times in multiple places, and I haven't seen any rebuttal by any Go representative.

You can ignore the community and do whatever is good for business, but it's hypocritical to pretend you're a "community-driven" project if you do that.

Spying on people without their consent is not ethical.

Is it not consent if you tell the user that it's on, how to turn it off, and the user confirms the prompt having decided to not disable telemetry?

Because that's how OP framed it. There is an ethical way to track how your app is used, with user consent.

Putting text on the screen which would inform the user if the user was to read and comprehend it is not consent, no. (I mean, try to apply that logic to any other situation. You put a post-it note somewhere noticeable which says that you will silently mix some medication into your coworker's lunch unless they write some text on another post-it note placed on the kitchen fridge. When you then notice the absence of that second post-it note, and mix in some medication into their food, is that "consent"?)

Furthermore, looking at the asciinema from OctoSQL, users apparently have to edit their profile files on every single machine they intend to use Go on, then remember to verify that the profile applies and has no typos, make sure to never ever accidentally run the program in a context where environment variables aren't respected (would you remember to always use `sudo -E` if you need to use the tool as another user for example?). The danger seems extremely high that the user would, at some point, accidentally run the command without the env var set, even if they were technically proficient and did their best to opt out.

This is not how consent works.

No because consent is required for it to be on in the first place.

How would you use compiler telemetry to spy on people?

Working hours, work location, home location, favourite cafes, sick days, vacations, hotels, wealth level. And that's just from IP addresses and timestamps alone, and without cross-referencing with all the data that Google vacuums over other channels.

That ship has already sailed. The Go tool already by default makes network requests to the Go proxy, which potentially allows everything that you're talking about there. What's significantly different about this telemetry proposal?

A couple things IMO.

First, making network requests when downloading packages is necessary for the tool to function and unavoidable. People who care about this will be using a VPN of some kind. It's just how the Internet works. But telemetry is something the tool author is choosing to add, not something that's necessary due to the architecture of our computing infrastructure.

Second, the Go telemetry would apparently create a unique, persistent user ID. Normal Internet use doesn't, there's just the IP address which is different from location to location, shared by a bunch of people behind the NAT, and can be masked using common tools.

And yeah, I know this is "anonymised"... but if you have one user ID which uses Go sometimes with an IP address from a particular apartment complex land sometimes from a particular office space, finding out which individual that user ID belongs to is trivial.

> First, making network requests when downloading packages is necessary for the tool to function and unavoidable.

It's technically not unavoidable. The Go authors could have made use of the proxy opt-in rather than opt-out, making the tool less usable as a result. A similar argument applies here, I think.

> Second, the Go telemetry would apparently create a unique, persistent user ID

Where did you see this? I scanned through the "Telemetry Design" article reasonably carefully and couldn't find any mention of this concept, and the type definition for the posted JSON (the `Report` type) doesn't seem to include any such user ID.

In the end, ISTM that you're not complaining about something that actually affects your privacy in any way, but just the _idea_ of telemetry. Is that really something worth taking such a hardline stance on?

> The Go tool already by default makes network requests to the Go proxy

Frankly, that crap should be expunged from the Go toolchain as well. :(

What is the argument for opt-out telemetry being unethical?

Because it most likely means that people are sending data without their consent. Perhaps I am naive or just very old, but I wouldn't expect a compiler to "phone home" with information about what I do with it. Certainly not without me expressing consent first.

So if you want that information, find a way to ask the user first. If you can give a good and understandable explanation on how the information is useful, the users might give their consent happily.

I don't think it's all telemetry. I suppose telemetry could be designed in a way that preserves the users privacy to an extent that is compatible with their native assumption. I suppose that design also depends on what you're building.

If you're building a website, I think it's fairly reasonable for you to store my IP. That's inside my expected privacy loss when dealing with a remote party. I have to connect to your computer, much like i have to physically walk into a store. I don't mind you remembering that I was there. Running a compiler on the other hand feels more "private" to me somehow. My expectation when using a compiler is that it won't send anything to anyone, because why would it?

In general I think our industry is starved for relevant and foundational ethics research, outside of the FSF at least.

Because that goes against informed consent.

Opt-out is generally rejected by European privacy laws.

> Opt-out is generally rejected by European privacy laws.

...where personal data is involved.

It strikes me that this proposal goes to considerable lengths to avoid collecting anything that could be considered personal data.

IANAL but European law is nuanced over whether IP addresses are PII. If I'm not mistaken it's been ruled they are for ISPs, rationale being they have enough other data points that once correlated with IP addresses allow to identify individuals. Whether the same applies to Google (I suppose) is definitely not clear to me.

The proposal explicitly says they don't collect IP addresses or _any_ unique identifiers.

As far as I'm aware/recall, European privacy laws consider any connection back to a telemetry server to count as "collecting" IP addresses, since the telemetry server learns it (even if they pinky swear not to write it down.)

You don't recall perfectly well.

Storing IP addresses in logs means that you are now responsible for them, yes. Drop them out of your logs, and you're perfectly fine.

I think privacy laws only apply to things that “process” PII. Accepting a network connection is not, in and of itself, considered to process PII.

Can you send telemetry data through Tor, though? :thinking:

There are Court cases that have established that the very fact that a connection is being established constitutes a potential collection of IP adresses and needs to be declares under GDPR. (this was specifically about sites using links to Google Fonts on their websites, this was enough to warrant a GDPR declaration that IP are being collected or the sites needed to remove their Font CDNs and supply them locally). Under the same Rule, Companies will need to ddeclare this usage of Go Compiler in their employee GDPR declaritions.

I assumed you need consent to receive PII, full stop. Again IANAL, but I assumed saying you don't do anything at all with the PII you receive doesn't exempt you from anything under GDPR. I may be wrong, though I hope not to be.

I agree it does do that though for context of others reading the thread personal data is a very broad topic:

https://gdpr.eu/eu-gdpr-personal-data/

You have to be very careful to do it properly.

> The idea of telemetry is being able to prioritize the work that will be most widely useful.

It does sort of hinge on the highly suspect assumption that usefulness is correlated with use. An obvious counter-example to this is something like a fire-extinguisher, which will in the ideal case just sit on a wall until it's use-by date passes and then it's discarded having never been used; or on the flip side, an incredibly byzantine workflow that could be reduced to something much simpler will appear important and useful.

Even without these edge cases, interpreting statistics is really hard. Like people with PhDs who have studied these things for years still get them wrong all the time.

What ends up happening more often than not is it's used as a tool to quiet the critics when pushing through unpopular changes.

Most software features are not like fire extinguishers.

More than that, the interesting stats may be not even around user-visible features, but around internal mechanisms, like some cache hit rate, or how often is some branch in the compiler invoked.

As long as stats are clearly inspectable, reasonably anonymized, and are opt-out, I'd be fine with sending them.

There are essential, fire-extinguisher-like features. The canonical example is the joke about backup software: if it were developed according to today's standard of telemetry-driven engagement analytics, the restore from backup functionality would be removed because it's used so infrequently.

This actually happens sometimes: when developing the demo ".kkrieger", a first-person 3D shooter in 96 KiB, demogroup theprodukkt tried to shrink it down to get it under the 96 KiB wire. One of the tricks they used was using a profiler to identify code sections that were never reached and could be removed. One of the sections they removed was the handler for the up arrow key in the main menu, simply because the test player never pressed up in the menu.

If you think that Google or another large software organization won't misuse telemetry by cutting or neglecting important but infrequently used functionality to hit some KPI... have you ever worked in a large software organization?

All stats can be deanonymized. The more data you make available, the more you identify yourself. I do not need software I use stealthily tying up bandwidth by "phoning home" with data about me. It is simultaneously betrayal and resource theft. If I wanted to contribute to the improvement of the software, I'd file a bug report.

I think your view of the ways usage stats are used is a bit simplistic. Not everyone remove "underused" features without giving some consideration, even in big corporations.

But since you clearly don't like telemetry, you should have a way to reliably switch it off. Here we are on the same page: there must be a well-documented and easy way to switch any telemetry off.

If telemetry is on by default, the vendor obviously wants you to have telemetry on. They are incentivized to make switching it off as difficult as possible, and even pull tricks like turning it back on after a delay of 7 or 30 days or so.

Telemetry should be opt-in, if it's provided at all.

The features that are like fire extinguishers are the ones most likely to be unjustly removed with the rationale of looking at telemetry.

See for example Mozilla's bizarre decision to remove the ability to change the override the character encoding of a webpage with some half-baked detector.

We cant solve this problem by carving out our eyes. We must adapt to having data about the world.

If folks were using just their eyes, they'd be calling users in to watch them interact with the software, calling users up to perform user surveys, doing all sorts of live-user testing.

But, that costs money: folks don't generally like to do surveys for free, don't like to come to your site (or have you come to theirs) for free, don't like to participate in tests for free... and the caliber of person who can design and orchestrate all that is _notably_ expensive.

So, companies have discovered that it's far, far cheaper to shove remote eyes into their products. No need to schedule user observation sessions, pay for transportation and participation, have to bother with hiring people who are capable of coming up with a good set of questions and scenarios to walk through.

Except that those remote eyes don't look at what a person would look at. They know if a feature was used but they cannot see the frustration on the face of a user when some feature is missing or does not work as expected or is hard to find.

Nobody wants you to carve out your eyes. They want you to stop shoving eyes into everything you touch.

Meanwhile, I'll decide what I must or must not adapt to, thank you.