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

https://opinionatedgeek.com/Blog/2017/3/26/your-tools-shouldn-t-spy-on-you

by mel919 • 9 years ago

142 90 9 years ago

opinionatedgeek.com

0xFFC• 9 years ago

tl;dr please?

mel9194• 9 years ago

Microsoft introduced telemetry enabled by default to .NET Core CLI.

dvfjsdhgfv• 9 years ago

The OP is not happy with the fact collects the telemetry data when you use their .NET tools and demands that they stop. (I'm almost sure this post will be featured on n-gate.com.)

orf• 9 years ago

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/5a37290f24aba5d35f3f95830...

They also publish all the telemetry data (Change 2016 and q3): https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...

1. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

Avalaxy• 9 years ago

So this is yet another case of someome blowing something completely out of proportions and spending their time working on something completely useless that will never benefit them.

princekolt• 9 years ago

"Out of proportions" for now. Nothing stops them from changing this later, updating the small print saying "oh we changed that" and blaming you for not checking for changes to their EULA regularly.

merb2• 9 years ago

do you actually inspect every github commit, that this won't change?

shakna7• 9 years ago

It already has. [0]

[0] https://github.com/dotnet/docs/pull/2706/files

sundvor• 9 years ago

Thanks. As I was scanning through the article, this is exactly what I was looking for but couldn't quite see for all the salt.

0xcoffee• 9 years ago

Also, when you run `dotnet restore`, you get the following message:

  Welcome to .NET Core!
  ---------------------
  Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.

  Telemetry
  --------------
  The .NET Core tools collect usage data in order to improve your experience.
  The data is anonymous and does not include command-line arguments. The data is collected by Microsoft and shared with the community.
  You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
  You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.

  Configuring...
  -------------------
  A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete   and will only happen once.

Sure its enabled by default, but at least they clearly notify you about it. So its strange that the author says: 'I’ve been using the dotnet core since well before then and I never knew about this.'

blub3• 9 years ago

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.

shakna7• 9 years ago

That's not quite correct. More is collected, but the docs are still being updated. [0]

The other things being collected are:

* Geographical location

* Operating system and version

[0] https://github.com/dotnet/docs/pull/2706/files

bjpbakker• 9 years ago

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.

pjmlp• 9 years ago

So I assume you don't use web apps.

FooBarWidget• 9 years ago

do you /trust/ MS ?

Why do you have to trust MS? You can read the source code to check for yourself whether sensitive information is sent. You don't have to take Microsoft's word for it.

lightbyte2• 9 years ago

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.

JadeNB• 9 years ago

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.

cm2187• 9 years ago

Well, as long as you make sure that the project name doesn't give away anything that could compete with a Microsoft product or that would leak information about some confidential product you are working on...

It's not just independent devs that are using .net. And the name of the company appears often in the assembly.

grkvlt• 9 years ago

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

wereHamster2• 9 years ago

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.

simooooo• 9 years ago

I'll just set the environment variable thanks.

wereHamster2• 9 years ago

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

apk-d• 9 years ago

This probably feels more unusual in the world of shell-based development tools - not many these days blink an eye for this sort of behaviour from an IDE package. Still, as a .NET core fan, definitely not a fan of this practice. To be expected from Microsoft, though - they bet big on telemetry in their tools and encourage developers to do the same (through tools like App Insights, for example).

mattmanser• 9 years ago

My impression is that no-one uses Application Insights. Total of 643 questions about Application Insights on SO, either it's the easiest tool to use ever, or no-one uses it.

staticelf4• 9 years ago

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.

shakna7• 9 years ago

and basically any site today does more intrusive telemetry

So the next version of Bash should have telemetry?

staticelf4• 9 years ago

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

taspeotis• 9 years ago

Here's what Microsoft have learnt from the telemetry [1].

[1] https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...

shakna7• 9 years ago

The data is also public, at:

https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...

So, the latest would be:

https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...

0x02• 9 years ago

I think it's noteworthy that they even include command line arguments that are mistyped, for example "bulid".

What happens if you accidentally paste an AWS secret key or similar in the middle of a command line argument? Will that too appear in public csv files a year later?

forgottenacc57• 9 years ago

People remain the same people and companies remain the same companies.

It's in microsofts DNA to build stuff that captures and watches and monitors and logs.

Just because they've started to be more open, won't change the fundamental company attitude and approach to doing things.

Microsoft will simply be bringing more "Microsoftiness" to the open source world. Get used to it, there's more coming cause that's the way they build software.

I would suggest that it is time to rethink some of those outdated assumptions that tools won't spy on you. Microsoft have arrived at the open source party, so open source isn't the same any more, just accept that the world has changed and now it's entirely possible that your open source is logging and watching.

yread• 9 years ago

Should have [2016] added to the title

https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin...

romanovcode• 9 years ago

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

mel9194• 9 years ago

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.

strictnein• 9 years ago

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?

RubyPinch• 9 years ago

"You should be able to run a command that doesn’t use the network, knowing that it won’t open a network port." Is the reader supposed to stop reading there? Because they must be using a different dotnet than everyone else, considering microsoft's dotnet does package management and download iirc?

"I don’t want your tools spying on you either." how virtuous. Some people don't care though, some people actually prefer it

Silhouette• 9 years ago

"I don’t want your tools spying on you either." how virtuous. Some people don't care though, some people actually prefer it

Then it won't be a problem to disclose exactly what is proposed, get those people's informed consent, and leave everyone else alone, will it?

_pmf_• 9 years ago

"Telemetry" ... nice spin.

marenkay• 9 years ago

What's with this exaggerated blog post?

1. It was announced in the open in June 2016 that .NET Core includes telemetry: https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcin... 2. If you use something you could at least follow changes between major releases, no?

When did engineer stop being responsible people and read before using things? :-O

cjsuk6• 9 years ago

Coming from Europe, I'm a little worried by the general attitude here. We tend to side with privacy first. There are some real genuine concerns from real people like myself who have to work with this tooling. I'll detail my thoughts:

1. It's setting a bad precedence for data collection by default. Name one other tool of the same class that actually sends telemetry data home by default?

2. It's much harder to ensure that the tooling is compliant with data protection policies within an organisation if the tooling by default sends telemetry. We now have to assume it's going to send stuff by default and configure all build infrastructure, every developer workstation and every piece of the toolchain independently. This is particularly of concern in the finance sector. It also costs us time and money.

3. There's no test cases to cover the telemetry functionality at all. Check the code. What happens if it starts reporting command lines due to a trivial defect.

4. There is a crudely defined document which describes what the telemetry does, but not what it will do in the future. What happens is a PR appears, gets merged and gets pushed out to a new version. To find out what happens you have to read every merge, every PR for a release.

This is a loaded gun waiting for any security conscious team to shoot themselves in the face with. Really this will gate the product into the bin at the first technical review stage for a lot of companies. There is no appetite for being milked.

I'd also like to add the absolute zero communications on this front from MSFT. People have asked directly via PRs to turn this off because they do not want it and they have been ignored for over a year. The usual response from MSFT is never to respond directly to this question and instead outline what the telemetry does expecting the question to remain answered. If there's anything I've learned over the years; you can't trust anyone who won't answer a direct question.

Sir_Cmpwn• 9 years ago

Though this data is more or less benine, the point remains. I don't think it's appropriate for a tool like this to phone home, and if it did, it should at least be opt-in, not opt-out (especially considering the opt-out mechanism is something as clumsy as setting an environment variable rather than a config somewhere).

This tool compiles code. Why does it need to make a network call at all? That's going to slow down your builds for the sake of phoning home to Microsoft, a company we don't exactly trust for being good stewards of our information.

raprp• 9 years ago

This has been discussed for over an year on this issue: https://github.com/dotnet/cli/issues/3093

They are just ignoring to let the issue die silently.

amelius• 9 years ago

I'm not sure what their goal is with this data.

Do they want to use this data to create a good tool?

Or do they want to use the data to create a tool that appeals to the average user?

zabil3• 9 years ago

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 published an blog post https://blog.getgauge.io/why-we-collect-data-b19df366b677 and will put it up in the release notes and the download section.

What else can be done so that users don't blow up?

blub3• 9 years ago

The minimum should be a clearly presented option to turn off telemetry either during install or at first startup.

mel9194• 9 years ago

Just a mere suggestion: you may look into how it's done in yeoman (https://github.com/dotnet/cli/issues/3093#issuecomment-22034...) and read this https://github.com/dotnet/cli/issues/3093 as there's lots of user input there.

cjsuk6• 9 years ago

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.

swsieber• 9 years ago

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]:

Piccollo• 9 years ago

"telemetry", what a euphemism.

shanselman• 9 years ago

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.

yuhong• 9 years ago

My favorite actually is https://github.com/dotnet/cli/pull/3494 . Of course sending things like IP addresses is unavoidable. I should also mention https://twitter.com/NerdPyle/status/863456558172168192

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

Related Stories