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

81–90 of 101 posts

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

#81

Post by jdmichal »

strictnein wrote: post #79
mel919 wrote: post #33

Earlier quoted context omitted.

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?

I've struggled with this before on this site. People love to pull out fallacies. But they forget that fallacies are only fallacies if they are used as a counterargument. And even when they are used in such a way, the other side then has to deal with fallacy fallacy. You can't immediately discredit an argument just because it contains a fallacy.

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

#82

Post by staticelf »

shakna wrote: post #46
staticelf wrote: post #12

Come on folks, this is printed out on the use of the command and basically any site today does more intrusive telemetry. I think they should ask people like Yeoman, but I don't think they deserve this much shit for such a small thing.

> and basically any site today does more intrusive telemetry So the next version of Bash should have telemetry?

No but it's big differences in the projects. If Powershell would have gotten telemetry I would understand the objections.

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

#83

Post by simooooo »

wereHamster wrote: post #5

On mac you can always use little snitch ( https://www.obdev.at/products/littlesnitch/index.html ) to reliably block outgoing connections. No need to muck around with environment variables, and you don't have to guess which domains dotnet uses, little snitch will tell you, even if they change them in the future.

I'll just set the environment variable thanks.

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

#84

Post by shanselman »

It's somewhat ironic that he feels so strongly about privacy but when I hit his site I get this message: "This website uses cookies to ensure you get the best experience on our website - More info" that links to Google's policy. Regardless, as folks point out, you're notified https://news.ycombinator.com/item?id=14837097 so it's not clear when he missed this.

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

#85

Post by wereHamster »

simooooo wrote: post #83
wereHamster wrote: post #5

On mac you can always use little snitch ( https://www.obdev.at/products/littlesnitch/index.html ) to reliably block outgoing connections. No need to muck around with environment variables, and you don't have to guess which domains dotnet uses, little snitch will tell you, even if they change them in the future.

I'll just set the environment variable thanks.

Haha, who makes sure that dotnet actually honors the env variable? It could still connect to servers and exfiltrate data.

OTOH nobody gets around a firewall which blocks all outgoing connections ;)

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

#86

Post by winthrowe »

zabil wrote: post #77
swsieber wrote: post #74

Earlier quoted context omitted.

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

If you're setting up automated non-interactive installs, your job is to check for install failures and consult the documentation; I know that's part of my job.

I'd recommend a required installer flag forcing the user to make a decision, but I'm a user who generally leaves telemetry on.

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

#88

Post by JadeNB »

bjpbakker wrote: post #21
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…

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

Bear with me. This seems like the wrong question, but not for the reason you might expect. Rather, I think that it might be wrong because, even if Microsoft acts in completely good faith, it is damn near impossible to anonymise collected data properly [obligatory citation of the 'anonymised' AOL search data]. It doesn't matter whether I trust someone to do something if they (probably) can't do it.

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

#89

Post by moron4hire »

cjsuk wrote: post #57
Guvante wrote: post #55

Earlier quoted context omitted.

Why? Defaults are important and the vast majority don't care (assuming correctly selected telemetry data) and the majority can't be bothered to change the default in either case. Again I am making a huge assumption about correctly selected telemetry data here but opt in mechanisms won't get even 10% of the data they currently do.

Defaults should respect the user first. Consent has to be given, not taken as a default. Sure ask up front explicitly but don't in passing invoke the first capture before consent has been taken. That's a shitty tactic.

Collecting basic usage data is not disrespecting the user.

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

#90

Post by concede_pluto »

moron4hire wrote: post #89
cjsuk wrote: post #57

Earlier quoted context omitted.

Defaults should respect the user first. Consent has to be given, not taken as a default. Sure ask up front explicitly but don't in passing invoke the first capture before consent has been taken. That's a shitty tactic.

Collecting basic usage data is not disrespecting the user.

It is when you know you can't persuade them you have a good-enough reason to need it, so instead you don't even try.
Post reply on HN