Hacker News Reader

Comment by saurik | Hacker News Reader

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!!

View on HN

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.

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. :(

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.

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.

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.

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.)

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

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.

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 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.

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.

Reply on news.ycombinator.com