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

Microsoft/.Net Foundation added telemetry to the dotnet command line last year

opinionatedgeek.com

Post reply on HN
Print view View original

71–80 of 101 posts

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#71

Post by cjsuk »

zabil wrote: post #68

We are struggling, philosophically, with anti telemetry posts (like this one). We are turning on telemetry in the next release for our open source tool. https://github.com/getgauge/gauge We are small team with limited resources. In our tool, it's easy to turn telemetry off, inspect what data is sent and the data collected is public. The data "really" helps to make the tool better and an opt-in skews the data. We've p…

Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect.

If you get an uptake of say 5-10%, if that's worth it then problem solved. If it's not then don't bother adding telemetry to start with.

But before you do this, you have to ask the question: how did the software industry get by before the sudden rise of telemetry? It engaged the customer.

I think a lot of cases it is used it is used as a substitute for engaging the customer.

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#72

Post by msla »

nolok wrote: post #28
blub wrote: post #19

Earlier quoted context omitted.

The author must not be used to the new spyware-by-default mentality coming from Microsoft. Hard to believe, but they used to sell products a while ago and had no telemetry. If you want to see how it's done properly, look at OmniGroup: their apps have toggleable telemetry and it's off by default.

> The author must not be used to the new spyware-by-default mentality coming from Microsoft. Hard to believe, but they used to sell products a while ago and had no telemetry. Yeah well you and the author's first clue should have been when you stopped paying for said products. And in this specific case, it's really not spying, it reveals pretty much nothing about you and help them figure out what is used and what fail…

I use a ton of software I don't pay for which also doesn't spy on me.

Or are you making some weird accusations against the FSF and the GNU Project?

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#73

Post by msla »

lightbyte wrote: post #50
bjpbakker wrote: post #21

Earlier quoted context omitted.

> For reference, they collect That's not all that matters. IMO the real decision is: do you /trust/ MS ? Do you trust that they anonymize collected data and that they won't secretly change collected data? Do you trust future MS with that information. > I'm actually OK with this to be honest That's perfectly fine if you trust them. Many people don't. Personally I wouldn't trust any dev tool that uploads my usage.

>That's not all that matters. IMO the real decision is: do you /trust/ MS ? Do you trust that they anonymize collected data and that they won't secretly change collected data? Do you trust future MS with that information. You don't need to trust them. The telemetry code is open source AND they release the aggregate data it collects for anyone to use/inspect.

If it's completely open, how do they keep it from being spammed?

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#74

Post by swsieber »

cjsuk wrote: post #71
zabil wrote: post #68

We are struggling, philosophically, with anti telemetry posts (like this one). We are turning on telemetry in the next release for our open source tool. https://github.com/getgauge/gauge We are small team with limited resources. In our tool, it's easy to turn telemetry off, inspect what data is sent and the data collected is public. The data "really" helps to make the tool better and an opt-in skews the data. We've p…

Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect. If…

Indeed. Though on-by-default telemetry gets a different set of data than engaging with the customer.

If adding telemetry is faster and easier than engaging with the customer, then you'll see projects that add telemetry that wouldn't otherwise have the bandwidth to engage with the customer.

In general, I think the best way to go is to ask in the installer or initial setup, whether you want to send telemetry, and have a sane default according to whether you gather potentially personal information (location? personal, commands run (without args), not personal).

Example Prompt: Send telemetry (commands used, version) (y/n)[y]:

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#75

Post by grkvlt »

orf wrote: post #3

For reference, they collect[1]: The command being used (for example, "build", "restore") The ExitCode of the command For test projects, the test runner being used The timestamp of invocation The framework used Whether runtime IDs are present in the "runtimes" node The CLI version being used I'm actually OK with this to be honest. Here is the telemetry code itself: https://github.com/dotnet/cli/blob/5a37290f24aba5d35f…

And, the 'secret' environment variable to disable it is actually printed in the text of the last (installation successful) dialog of the install wizard, at least on OSX for the 2.0.0 preview...

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#76

Post by j_s »

vetinari wrote: post #63
j_s wrote: post #59

Earlier quoted context omitted.

Firefox tracks users with Google Analytics in the add-on settings | https://news.ycombinator.com/item?id=14753546 "Someone submitted a PR to Mozilla to fix this, and the Mozilla devs closed it" Impossible to opt-out until about 2 weeks ago.

Come on, that was a bug in the new preferences pages. The telemetry I was talking about is exactly the one, where you get a bar at the bottom during first launch. Try it, you will see it.

Perhaps this instance was an honest mistake.

The specifics of a custom deal with Google and the circling of the wagons (specifically opinions expressed by multiple Mozilla employees in an official capacity) prior to reversing course does not strengthen that case.

> If you say no, it won't send anything.

This simply wasn't true; I am glad that the implementation was fixed.

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#77

Post by zabil »

swsieber wrote: post #74
cjsuk wrote: post #71

Earlier quoted context omitted.

Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect. If…

Indeed. Though on-by-default telemetry gets a different set of data than engaging with the customer. If adding telemetry is faster and easier than engaging with the customer, then you'll see projects that add telemetry that wouldn't otherwise have the bandwidth to engage with the customer. In general, I think the best way to go is to ask in the installer or initial setup, whether you want to send telemetry, and have…

We've experimented asking users on install or initial setup. But most of the time our tool runs in non interactive environments e.g. on a CI/CD set up (install and execution).

An additional flag for non-interactive installs can solve the problem, but that's a broken setup experience, someone has to look up the documentation after a failure to install.

Turning it off by default in case of a CI/CD setup means losing most of the data.

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#79

Post by strictnein »

mel919 wrote: post #33
romanovcode wrote: post #25

If you are so against telemetry and google analytics specifically maybe you should remove it from your own site?[0] [0] https://imgur.com/a/NX2Gc

I'm not the author of the blog post. I think you're comparing apples and oranges, also this kind of reasoning is an example of "tu quoque" logical fallacy.

> tu quoque

No, this is not that. The "tu quoque" logical fallacy follows this pattern (from Wikipedia):

   Person A makes claim X.
   Person B asserts that A's actions or past claims are inconsistent with the truth of claim X.
   Therefore X is false.[2]
They are not saying their claim is false. They're saying that if they care so much, why are they subjecting their users to tracking that they are unable to opt out of?

Re: Microsoft/.Net Foundation added telemetry to the dotnet command line last year

#80

Post by runfaster2000 »

0x0 wrote: post #60
lightbyte wrote: post #53

Earlier quoted context omitted.

They don't include command line arguments (yet). They include the command verb (dotnet [build/restore/etc]) that was ran.

Well, it looks like they are including "command verbs" even if they are mistyped, for example "bulid". What happens if you accidentally paste an AWS secret key or similar in the middle of a command verb? Will that too appear in public csv files a year later?

See my comment to the grandparent comment on our approach to only including common command strings (which wouldn't include anyone's AWS key). Also, and more importantly, we will only collect known arguments. From the blog post:

> Only known arguments and options will be collected (not arbitrary strings).

We don't want your AWS secret key in this data as much as you do. We have put systematic mitigations in place to ensure that this doesn't happen.

Post reply on HN