Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transparent telemetry for open-source projects

research.swtch.com

Post reply on HN
Print view View original

291–300 of 314 posts

Re: Transparent telemetry for open-source projects

#291

Post by sidewndr46 »

chaps wrote: post #252
rsc wrote: post #150

Earlier quoted context omitted.

You can also echo GOTELEMETRY=off >> $(go env GOENV)

There are tons of cases where the person installing go won't know that telemetry is enabled otherwise. For example, let's say you're at a bootcamp and the go installation instructions from your teacher don't mention telemetry -- how would the person know to disable telemetry? My concerns are around nation state actors, domestic abuse, journalist privacy, lawyer confidentiality and fully believe that this sort of tele…

If you run your build inside of a docker container, wouldn't it be enabled by default as well? Docker containers do not inherit the environment from the host that I know of.

Re: Transparent telemetry for open-source projects

#292

Post by JohnFen »

philosopher1234 wrote: post #230
JohnFen wrote: post #181

Earlier quoted context omitted.

Perhaps we aren't so far apart after all. The struggle is real. As a developer, more data is obviously desirable and can make development much easier. I just can't think of a way to do telemetry that, if I were a user, I would accept. And I don't want to produce software that I wouldn't personally use. I just don't know how to have my cake and eat it too.

As a developer your entire purpose is to make decisions for users. "Where should this service live, how should security work, how should I increment their billed service usage, when should I shut down their vm..." I don't think the issue here is making decisions for users and not giving them a choice. 99.999% of software does not have a flag to change it. The issue seems to be more about the precise nature of this sp…

> The issue seems to be more about the precise nature of this specific feature.

Of course. Not really just this specific feature, but any and all features that can violate users privacy or security. In the end, I don't think these are decisions that developers should be making for users, because not all users have the same needs and getting this wrong can do harm.

That's why, for these sorts of things, meaningful user consent is critically important.

Re: Transparent telemetry for open-source projects

#293

Post by pcthrowaway »

yencabulator wrote: post #289
pcthrowaway wrote: post #248

Earlier quoted context omitted.

Just because Linux is open source doesn't mean you can't have both Fedora and Red Hat (an enterprise version built on the same codebase) I don't think any closed source goes into Red Hat, it's just the patch delivery pipelines, package repositories, etc that require a license. And support of course. Same with any distributed system whose core contributors could gain insight from telemetry. All the components are open…

You can make submitting telemetrics a condition of some other agreement, such as copyright license on the Red Hat name, or a B2B support contract. That, however, is pretty far removed from what's discussed here; if the software license itself makes telemetrics "mandatory", then it's no longer an open license.

I don't think I made myself clear.

The company ships one product which is a community edition of a bundle of open source software. That version has telemetry enabled and can't be disabled. Users who want to patch the code manually can of course disable it, just like they can disable the Ad lens in Ubuntu if they want to build it themselves, and those users will be off the beaten path and likely to run into issues that aren't easy to find paved solutions for.

They also offer an enterprise edition with a support license, on which telemetry is enabled by default, but can also be disabled.

Re: Transparent telemetry for open-source projects

#294

Post by pcthrowaway »

account42 wrote: post #290
pcthrowaway wrote: post #248

Earlier quoted context omitted.

Just because Linux is open source doesn't mean you can't have both Fedora and Red Hat (an enterprise version built on the same codebase) I don't think any closed source goes into Red Hat, it's just the patch delivery pipelines, package repositories, etc that require a license. And support of course. Same with any distributed system whose core contributors could gain insight from telemetry. All the components are open…

To be more explicit: If your license does not let users patch out your telemetry code it is not an open source license at all.

From my response to your sibling:

I don't think I made myself clear.

The company ships one product which is a community edition of a bundle of open source software. That version has telemetry enabled and can't be disabled. Users who want to patch the code manually can of course disable it, just like they can disable the Ad lens in Ubuntu if they want to build it themselves, and those users will be off the beaten path and likely to run into issues that aren't easy to find paved solutions for.S

They also offer an enterprise edition with a support license, on which telemetry is enabled by default, but can also be disabled.

Re: Transparent telemetry for open-source projects

#295

Post by bombela »

0xjnml wrote: post #268
bombela wrote: post #261

Earlier quoted context omitted.

You can find plenty of well articulated rant online. The gist is Go ignores all research in programming languages. Is very hard to use properly. It is really hard to produce safe APIs. You are encouraged to pop threads (preemptive user threads) all over the place. And may the god of lost state saves you from the hell of data races. Also what is this slice/vector type thing? Don't forget to check `err`, nope not this…

> The gist is Go ignores all research in programming languages. This is an assumption and it's IMHO false. Go creators watched all the research, probably closely, lived with its results and were not happy with what they get. Their experience reminded them that less features in a PL make it arguably less expressive, sure, but in the same time it makes it faster to learn and master, easier to read and debug. Writing to…

You start with a dizizlgy large amount states (RAM, storage, network, threads...). The goal of programming languages is to give you a way to reduce the vast number of states as much as possible. Without removing the ones you need to do the work. Each layer of abstraction reducing what is possible, without impeding the work that ultimately needs to be performed.

In my humble opinion, you should learn a bit more about, easy vs simple, complicated vs complex.

Re: Transparent telemetry for open-source projects

#296

Post by ohgodplsno »

gwillen wrote: post #200
Scaevolus wrote: post #194

Earlier quoted context omitted.

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.

Re: Transparent telemetry for open-source projects

#297

Post by yencabulator »

pcthrowaway wrote: post #293
yencabulator wrote: post #289

Earlier quoted context omitted.

You can make submitting telemetrics a condition of some other agreement, such as copyright license on the Red Hat name, or a B2B support contract. That, however, is pretty far removed from what's discussed here; if the software license itself makes telemetrics "mandatory", then it's no longer an open license.

I don't think I made myself clear. The company ships one product which is a community edition of a bundle of open source software. That version has telemetry enabled and can't be disabled. Users who want to patch the code manually can of course disable it, just like they can disable the Ad lens in Ubuntu if they want to build it themselves, and those users will be off the beaten path and likely to run into issues tha…

> bundle of open source software. That version has telemetry enabled and can't be disabled.

I'd recommend saying "and cannot be configured off without code changes", or something. Of course it can be disabled, if it's open source.

Go compiler without telemetrics opt-out would fragment the community even harder than Go compiler with telemetrics default on. While your scenario is, of course, possible, it's not very relevant to the Go compiler.

As for your original "might be a sustainable way to run an open source company", if the primary feature one gets buy paying is "easy to turn off telemetrics", that just doesn't sound like enough value.

Re: Transparent telemetry for open-source projects

#298

Post by chaps »

sidewndr46 wrote: post #291
chaps wrote: post #252

Earlier quoted context omitted.

There are tons of cases where the person installing go won't know that telemetry is enabled otherwise. For example, let's say you're at a bootcamp and the go installation instructions from your teacher don't mention telemetry -- how would the person know to disable telemetry? My concerns are around nation state actors, domestic abuse, journalist privacy, lawyer confidentiality and fully believe that this sort of tele…

If you run your build inside of a docker container, wouldn't it be enabled by default as well? Docker containers do not inherit the environment from the host that I know of.

From the description of the implementation, it would only send telemetry data after seven days of being on. So, yes, as long as the docker container is up for that long. I didn't see anything that mentions whether it would communicate to any telemetry server on initialization.

Re: Transparent telemetry for open-source projects

#299

Post by msla »

cube2222 wrote: post #69

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 do…

There's a reason it can't be opt-in: Google intends collect information about politically sensitive software and give that information to governments who wish to punish developers.

Re: Transparent telemetry for open-source projects

#300

Post by ragall »

0x6c6f6c wrote: post #203
mort96 wrote: post #195

Earlier quoted context omitted.

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.

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