Sdk: .NET core should not SPY on users by default

[ghost]

@blackdwarf @piotrMSFT I am very disappointed to discover that .NET core comes with a hidden and enabled spy utility that reports on its users. (Lakshanf/issue2066/telemetry dotnet/cli#2145). Apparently, MS has learned nothing from the backclash against Windows 10 spying on users. I suspect many will not want to install .NET core for this reason, which is a shame because .NET core is otherwise cool.

[richlander]

Our recent blog post discusses the addition of telemetry to the .NET Core tools. See: https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/#telemetry

Me and the folks on my team are motivated to provide a great product. As you can also see from the blog post, we've made some pretty dramatic changes in RC2. We believe that they are the right ones, but we need both feedback and usage data in order to help us find all of the rough edges. Usage data tends to be more objective in the aggregate and user feedback more insightful, so we do a better job when we have both available.

The data we collect does not identify individual users. We're only interested in aggregate data that we can use to identify trends. The telemetry feature is configurable, so you can turn it on/off at any time. It is also scoped, only applying to tools usage, not the rest of the product. We think that this is a good trade-off and recognize that not everyone will like it. We do know, however, that many people will like the product improvements that will come from this insight.

We intend to share the data. The presence of it will do a lot to define the scope of data. It will also give the community access to the same insight we have. We very much feel that improving .NET Core is a shared need and task. As an example, we would welcome a PR from the community that added another telemetry data point given a strong improvement reason and no loss in anonymity.

We are separately considering _opt-in_ runtime telemetry to learn more about crashes, GC pauses and startup time. There is no way we can get enough insight about the product without that kind of information. We are very focussed on constant improvement and will _transparently_ do what it takes to ensure the product is compelling and competitive.

As an aside, it's been a busy week with shipping RC2 and answering questions. I haven't actually looked at this data yet and I'm one of the primary consumers. I'll be doing that today or tomorrow. I'm looking forward to sharing my insights.

[guardrex]

@richlander

we need both feedback and usage data

Does the telemetry still include arguments provided to the dotnet command? In server hosting scenarios, some may have sensitive arguments passed to the command (for portable apps) that they wouldn't want leaked to MS.

and will transparently do what it takes

The program is not "transparent" IMO.

[terrajobst]

Does the telemetry still include arguments provided to the dotnet command?

My understanding is that this was recently discussed with our privacy team and we concluded that collecting the arguments themselves (hashed or not) is not acceptable per our privacy policies. Not sure whether the code already reflects that, but it's being worked on.

[terrajobst]

The program is not "transparent" IMO.

What would you accept as sufficiently transparent? Not trying to say that we already are sufficiently transparent; I'm trying to understand your concern and what we could do make it better. The product is worked on by various teams who all contribute to the same open source code base on GitHub. Clearly you think that's not sufficient, so I'd like to understand what process would address that.

[guardrex]

@terrajobst Ah! Thanks. I'm glad the arguments are safe on the server.

WRT transparency: There is no indication at the time of install that the dotnet cli is automatically opted-into data sharing. There's no checkbox that will set the opt-out env var. There's no note or link to the GH issue or a Docs page that describes the program and how to opt-out. The privacy policy merely links to the generic MS privacy policy, where there is no mention of the program.

You really have to have heard about this through the GH issues or via chat at JabbR or Slack ... or Wireshark your server I guess. In my mind, that hardly constitutes "transparency."

IMO there is a great risk here for negative PR if the mainstream media gets a hold of this issue that will not be good. It's only a matter of time before some enterprising journalist looking for a scoop picks up on this. The headlines here are not good: "Microsoft caught with sneaky program to spy on companies" ... I know ... I know ... barely accurate given what the data is, how it's shared, and it's use by the teams. You know that doesn't matter one bit when you're trying to sell a newspaper. I was a college newspaper editor. Trust me ... it will not be good if the current disclosures about this program hold to RTM.

[richlander]

@GuardRex This is good feedback. We do have a bit more to do to make sure that everything to with telemetry is obvious. We'll make sure that gets into the next release.

[ghost]

GuardRex is exactly right about the lack of transparency and danger you are in for a shitstorm, so it is a good idea to include a checkbox in the installer to make it visible!

Also, you should keep in mind the problem is both privacy AND security. As for security, I think that MS forget that a power user/developer may have hundreds of pieces of software installed. If all these pieces of software (in a stealthy way) report usage back to various servers on the internet, then the security attack surface becomes so large that it is impossible to secure the computer. Hence, many companies will ban your software (especially on Linux servers).

This particular "feature" may undo all the good things that MS is doing with .NET core. Even if I might personally be persuaded to risk my computer and privacy, some of my customers won't. Hence, I will be reluctant to base my development on .NET core because of the customer reaction to spying.

[vcsjones]

I would probably agree that people will be a little miffed by this. Homebrew for OS X recently went through this even though they were well intentioned, did it anonymously, and provided a way to opt out.

I think simply asking people on first use if they'd like to submit telemetry is a good start.

Consider what Yeoman does on first use:

I think people are generally happy to give feedback when asked.

[mmc41]

@blackdwarf
@piotrpMSFT
@richlander
In related news, VS2015 just got into big trouble because spy code was discovered:
https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/d30dmvu

You should consider learning from such mistakes!

[vcsjones]

Looks like issue dotnet/cli#3404 is tracking implementing notification of telemetry.

[h3smith]

@richlander - as someone looking to deploy projects built with this is healthcare and classified environments, this creates significant challenges. An environment variable is a decent starting point, but build time and local options should also be given to ensure that this data is not collected. I appreciate the desire of you guys, but it introduces security concerns.

[akoeplinger]

@GuardRex https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-net-core-1-0/#user-content-net-core-tools-telemetry shows the data points that are collected and the following statement which should make it pretty clear that telemetry only applies to the tools/CLI (i.e. dotnet):

The feature will not collect any personal data, such as usernames or emails. It will not scan your code and not extract any project-level data that can be considered sensitive, such as name, repo or author (if you set those in your project.json). We want to know how the tools are used, not what you are using the tools to build. If you find sensitive data being collected, that’s a bug. Please file an issue and it will be fixed.

[guardrex]

only applies to the tools/CLI (i.e. dotnet)

If you mean it only applies to executing a portable app using dotnet (dotnet .\myapp.dll) and not a self-contained app using corehost (myapp.exe) ... I don't think the language states that clearly. One has to know that you don't consider corehost to be a "tool," and that's not an assumption that I would make.

There is an on-going problem in assuming too much prior knowledge in communication with people (outside of the ASP.NET docs, where a major effort has been made to address this problem). I think writing docs with greater attention to explicit and comprehensive explanations, as annoying and time-consuming as that may be, clears up a great deal of confusion.

Setting this minor confusion aside, I greatly appreciate the effort that has been made to inform everyone about the telemetry program. I still wish that production servers weren't automatically opted-into the program, mostly because (just like @blackdwarf commented in a recent video interview I saw) I hate having to set and maintain env vars on servers ... a total PITA IMO.

[dlebedynskyi]

Guys, this issue is really important. A lot of projects ask for telemetry and it is ok. In fact for a bunch of those like yo, bower and so on dev like me willingly opt in.
But not asking using if he even want and referring to some elua that really no one will read smells. It is horrible negative PR.
Make option to opt in for use. Explain in details what you are going to collect and what not. Do not do it by default.
Otherwise we really will have to block feature or not use dotnet entirely. I really don't think that paranoid security team will even allow devs to deploy this now.

[kspeakman]

Discovering this telemetry has put the plans I had in using .NET Core back on the drawing board. You are essentially refusing to accept an arms-length relationship by including telemetry. Data leakage is a risk even if it isn't user specific. It also creates attack opportunities since attackers now have this plentiful and predictable avenue of communication to go after. Not to mention that once marketing gets wind (if they didn't help drive it in the first place), the data collection will be expanded. Save yourself work by creating more admin/security work for your users (to opt out or block telemetry). Just because it's an industry trend doesn't mean its a good thing to do.

[guardrex]

@kspeakman On the bright side, it is well controlled by the env var ...

https://github.com/dotnet/cli/blob/rel/1.0.0/src/dotnet/Telemetry.cs#L39-L44

... so at least if you add that via web.config, PowerShell, manually, or whatever ... it disables telemetry effectively. However, if you were more generally concerned about Microsoft.ApplicationInsights being on the server _at all_, then they have said that corehost doesn't have telemetry built-in, so you could go the self-contained app direction (no shared framework on the server) and avoid this entire issue. The only catch is that you need to pull the ASP.NET Core Module out and install that manually ... they don't have a standalone installer for the module yet (AFAIK), nor has it been spun off into OSS yet (but they are planning to do that).

[RomanShumikhin]

Is there any chance that this telemetry "feature" will be removed from the next version of the tools?
If not, I totally agree with the original poster, this should be opt-in, not opt-out.

[mschlechter]

At the very least, the dotnet program should ask on first run whether the user wants this or not.

First Windows 10 and now this.

I don't want telemetry. At all. It's fine when people are beta testing a product in a special testing environment, but not in production.

[rustybox]

This really needs to be opt in, I haven't been playing since beta 8. Got caught up this evening with some of the community standups and decided to have a go with the latest. Spent ages reading the privacy policy & community response and not clicking the agree button.

Yes it's easy to opt out, that's great but these sorts of things occurring make me just want to go hack on some python in emacs instead.

Help the community to trust the mega corp vendor, surely that's one of the aims of going open source?

[linkdata]

Making this opt-out instead of opt-in seems like really poor judgement. I understand and respect the need for you to collect some usage to help guide the .NET Core platform, but printing a few lines of text once before starting to send unspecified data over the 'net to some server is just disrespectful.

Please make it opt-in or remove it entirely.

[hardhub]

I vote to remove it fully from .Net Core source code.
It must be an external option, user should have ability to download some package to start statistics collection.

[ghost]

Since there hasn't been any post on this topic in a couple of months, I will share some insights having just come across this as a fresh (potential) adopter of Core CLR.

Just downloaded latest build of .NET core and just by luck noticed the unremarkable disclaimer after running one of the dotnet shell commands.

This is altogether ridiculous and comes on the heels of already-rediculous telemetry collection in their other products. I feel like Microsoft is saying publicly that they're not tone def to the community then they keep doing things like this.

I was starting to get excited about the implications of Core CLR and what that could mean for the expansion of C# (the language itself is really fantastic).

This automatic telemetry nonsense is a big reason why I shy away from the Windows platform entirely. It's not even about my own personal feelings or beliefs on privacy concerns and whatnot. It's about selling this platform to my company and my contracts. In an enterprise environment, getting people to trust Microsoft is already an uphill battle with many with my fellow developers and higher-ups. Making the case for using C# + Core CLR on Linux is MUCH easier than making the case for switching entirely to Windows.

However, this telemetry nonsense is simply a nonstarter. Imagine trying to sell this to someone already averse to monoliths and vendor lock-in (synonymous in our field with MS, for better or worse) then immediately having to defend telemetry collections (and the disablement thereof). We run production workloads in production data centers with enough infosec headaches already. Things like this are simply nonstarters for many executives. Sure, we can add an environment flag, but when has someone EVER forgotten to do that?

Alas, I am beginning to feel that Core CLR will go the way of Windows 10: admittedly great technology crippled by corporate nonsense that makes many developers just go look for some alternative when choosing a tech stack that doesn't come laden with such nonsense.

TL;DR; turn this crap off. You're pissing off the people you claim to be building tools for.

[CodesInChaos]

How about checking HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry and disabling telemetry when it exists and is 0 in addition to your product specific opt-out? Users who don't want Windows telemetry almost certainly don't want .NET telemetry either.

[hardhub]

@CodesInChaos, .Net Core can run on Linux...
And I personally think some flag wherever is bad idea... as well as any assumptions...
User should be able to control all in obvious way.

[vcsjones]

@hardhub

in addition to your product specific opt-out

CodesInChaos is suggesting that if the platform is Windows and they opted out of Windows telemetry, then just assume "no" telemetry. Otherwise, allow the user to make a selection.

[hardhub]

@vcsjones

I see... And I mentioned what Linux guys should do? And no Windows Enterprise 10 users?
I think some registry key somewhere is not good idea for user privacy... not enough obvious.
It should be available very easy and disabled by default... I personally suggested to enable telemetry as package. Google, for example, does not force us to use GA....

[OpinionatedGeek]

In the interests of transparency, please let us all know which hostnames/servers to which the data is sent.

This will also allow people to block this traffic once, at the network level, instead of having to update every RC file for every shell for every user for every machine.

[vcsjones]

@OpinionatedGeek

In the interests of transparency, please let us all know which hostnames/servers to which the data is sent.

Telemetry is collected using Application Insights, to my knowledge. The documentation for their endpoints and IPs is here: https://docs.microsoft.com/en-us/azure/application-insights/app-insights-ip-addresses

[OpinionatedGeek]

@vcsjones Many thanks for that link and those hostnames. It's a very handy reference!

Can anyone from Microsoft confirm or deny that this is the full, correct list? I note that blocking all the listed hostnames would mean blocking access to hosts like login.windows.net and packages.nuget.org - hosts Microsoft probably doesn't want blocked.

Many thanks.

[vcsjones]

The ones specifically for telemetry are dc.services.visualstudio.com and dc.applicationinsights.microsoft.com. The rest are for ApplicationInsights, but aren't categorized as Telemetry.

Keep in mind this would affect any application that uses Application Insights, not just the SDK.

[OpinionatedGeek]

I'd still like to hear from Microsoft the official list of servers to which the telemetry is sent. Can someone from Microsoft please reply with these details?

The telemetry hostnames aren't in the dotnet CLI code base as far as I can tell, and I don't want to just assume that the hosts are the same as the 'Azure Application Insights' hosts, or that they remain the same across all OSs.

[slawo]

I also agree, telemetry should be an option activated only after the user's explicit authorisation or through: export DOTNET_CLI_TELEMETRY_OPTIN=1.

[chrisjsmith]

So it's been months. Nothing from MSFT. Clearly avoiding the discussion...

[hardhub]

@chrisjsmith

Each company pursues its selfish interests ...

Hey MS! Tons of bugs is not what open source world means...
It means to be open and ready to collaborate with people.

[vcsjones]

I thought to better frame this discussion it might be worth while to explore what telemetry is collected. I did my best to capture this, and have probably gotten some of this wrong.

1. The name of the command that is run, like dotnet *foo*. https://github.com/dotnet/cli/blob/58c580dbcc212846d38820d015e73f2d7e80214e/src/dotnet/Program.cs#L148. It does not appear to collect the arguments passed to the command.

2. When installation is complete successfully. It appears to also collect the name of the exe files that did the installation. https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f958300aa20329e5ccaa7/src/dotnet/commands/dotnet-internal-reportinstallsuccess/InternalReportinstallsuccessCommand.cs#L33

3. Any telemetry logged by MSbuild. This is done by creating a logger and handling only telemetry events from MSBuild. This is a rather complicated subject in MSBuild and wasn't very easy for me to follow, so if there are concerns of interest in MSBuild telemetry, perhaps the issue is best raised there.

4. Detailed information about dotnet new. However, none of this appears to contain personal information. It is mostly the template and language that is used in dotnet new, or if you used the help parameter. https://github.com/dotnet/templating/blob/rel/vs2017/3-Preview3/src/Microsoft.TemplateEngine.Cli/New3Command.cs#L916

[hardhub]

@vcsjones

Thanks for information...
But it does not matter... which exactly info is collected. It matters only for user which accepts it!
We just said that anybody should have a CHOICE to enable it or never enable it.
Let's say it is something like GA added to your app.. You know that Google can collect some big data... But you accept this... it is your choice.. you ADDED it yourself because it seems OK for you to share this info with Google to get good stats. But with this telemetry we have to find a way to avoid an imposed "features". It is abnormal even if MS wants to do its best.

[guardrex]

Folks ... good peeps ... plz ... just set the env var ...

... and take a look at ...

https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f958300aa20329e5ccaa7/src/dotnet/Telemetry.cs#L42

You're good after that. The problem early on was simply that it wasn't clear if/when/what was being collected and exactly how to get out of telemetry. Now, they make it super clear that if you just set the var you're NOT tracked. It's also spelled out now what is being collected: https://docs.microsoft.com/dotnet/core/tools/telemetry

[chrisjsmith]

That's misspelled. It should be OPTIN.

Rationale for this being a bad idea:

1. This defines the set of data currently collected. If this changes, it may collect more data. That means to ensure that it doesn't leak data, you have to audit every release to ensure telemetry hasn't changed.
2. There's no test case.
3. It, as most MSFT products these days, shows absolutely no respect for the end user's preferences.
4. EU Article 29 Working Party are still miffed about the opt-out Windows 10 telemetry. Adding it to your development tool chain is just throwing gas on the fire.

There's enough case to change this to opt in. This is met with silence which is unacceptable. It's like the MS Connect issue I opened against IE9 after they broke ClickOnce when the new download bar turned up. Suck it up and accept it and when you provide evidence, silence.

Go doesn't call home.

Python doesn't call home.

Vim doesn't call home.

Hang on I think I just solved the problem...

[guardrex]

It's not misspelled. One must opt-out by setting a value of true or 1 ("yes" used to work, too) ...

https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f958300aa20329e5ccaa7/src/dotnet/Telemetry.cs#L26

[edit] I think what ur referring to was an earlier post where the comment was that it should be opt-in.

[chrisjsmith]

So much for being facetious.

"yes used to work too" is an indicator of how broken it is. Does it work now? Where's that test case?

[guardrex]

Thx @benaadams ... we need to update the topic. I'll take care of it.

[benaadams]

The telemetry data is being shared now; and you can also download it:

What we’ve learned from .NET Core SDK Telemetry

We are releasing .NET Core SDK usage data that has been collected by the .NET Core CLI. We have been using this data to determine the most common CLI scenarios, the distribution of operating systems and to answer other questions we’ve had, as described below.

As an open source application platform that collects usage data via an SDK, it is important that all developers that work on the project have access to usage data in order to fully participate in and understand design choices and propose product changes. This is now the case with .NET Core.

.NET Core telemetry was first announced in the .NET Core 1.0 RC2 and .NET Core 1.0 RTW blog announcements. It is also documented in .NET Core telemetry docs.

We will release new data on a quarterly schedule going forward. The data is licensed with the Open Data Commons Attribution License.

...

And much more info at the blog post https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve-learned-from-net-core-sdk-telemetry/

[chrisjsmith]

I think MSFT is missing the point here. Opt out data collection is not welcome regardless of the outcome or data being collected. It may even be illegal in some jurisdictions. EU are about to explain this to you by the looks. Choice is what matters and respect for the end users which is not being displayed here.

This is indicated by the fact that every time telemetry is mentioned with any product that MSFT ships a very slightly different question is being answered. For example this thread clearly states that people want it removed and we're being responded to with "here's what we collected, it's not so bad". Same with windows 10 telemetry where the silence is deafening. Is it the party line inside MSFT to not answer the same questions and drown them out with marketing and blog posts?

On top of this it's quite difficult getting this past security controls in some corporates. If your product calls home by default you're off then tender list immediately. There is not even any discussion on the matter.

Transparency is not showing us what you collect, it is explicitly asking to collect it. You're running the "hey we're collecting data, jump through these hoops in every workstation, deployment environment and target to turn it off" model which isn't sometime most people will want. It also sets a new precedent which I at least am not entertaining.

[OpinionatedGeek]

FWIW @chrisjsmith I agree with you.

Given the utter lack of response to questions in this Issue, it might be worthwhile putting thoughtful remarks like these in a comment to the blog post. I commented and at least I got a response there.

[guardrex]

@OpinionatedGeek @chrisjsmith I'm working on the topic updates as you can see on https://github.com/dotnet/docs/pull/2706. Unfortunately, the review site, which would show a built version of the topic after the CI runs, doesn't work publicly. However, you can see the proposed updates if you look at the diff that seek to address the transparency concerns. I'm working through these updates with the following in mind: who, what, when, where, how, and why. If I haven't hit the sweet spot, I think I'm getting pretty darn close.

I think the 1st draft is just about done now. I'm going let that build this afternoon (takes 4-5 hours) and then take a final look. If you want to wait a little longer for my final checks, then just wait until I pull the WIP off of it, which I plan to do by the end of the day (Saturday, 7/22).

I invite you and everyone to take a look and provide feedback. Of course, the docs issue and PR only pertain to the coverage of the feature ... nothing about the presence of the feature itself should be discussed over there. This issue is the best place (or the blog post comments as you say) to discuss the presence of the feature or how it works.

To discuss language used in the PR, use the PR comments or attach comments directly to the lines of the diff. To discuss the coverage of the telemetry feature generally, please use the attached issue at: https://github.com/dotnet/docs/issues/2705.

Keep in mind that the updates are only a 1st draft subject to heavy revision and approval. What comes out of this process may even go as far as only making superficial changes to the current topic or a complete rejection of the PR itself. Just keep that in mind.

[hardhub]

Given the utter lack of response to questions in this Issue, it might be worthwhile putting thoughtful remarks like these in a comment to the blog post. I commented and at least I got a response there.

Maybe we have to put url to this topic there? ))

[h3smith]

While I agree with the sentiment here, if you look at Windows 10 logging, even when turned off by group policy it is sending data back to Microsoft. They clearly want to be gathering data in troves at a corporate level. I don't seeing this "feature" going away.

[OpinionatedGeek]

Maybe we have to put url to this topic there? ))

I already did @hardhub - here's the paragraph where I mention it:

Despite someone’s Github issue – https://github.com/dotnet/cli/issues/3093 – (over a year old and still running), despite someone else’s Pull Request – https://github.com/dotnet/cli/pull/7096 – switching telemetry off by default, we are in the situation where Microsoft now seems intent on making the tool’s spying even worse, all while talking about community engagement.

By all means add it again, if you believe it'll help.

[rafaelrpinto]

After more than 1 year, I guess this discussion is running in circles when there are only two obvious decisions to be made:

1 - Yes, we agree with the concerns raised here and will change the Telemetry to be OFF by default as proposed on dotnet/cli#7098.
2 - No, we want the data and will not ask permission before enabling telemetry. This software is free and if you want to use it read the instructions and disable the telemetry yourself. Or don't use it at all.

Any other discussion on sharing what's collected, better explanations and showing the benefits are just PR damage control for deciding option 2, which we all know some people won't like.

Just give us a plain NO and we won't bother raising concerns like this again.

[shravan2x]

Just throwing this in here: A trending HN article from a few hours ago https://news.ycombinator.com/item?id=14836737 .

[chrisjsmith]

I was just about to add that :)

[svick]

@rafaelrpinto

I think Microsoft's position has been a pretty clear NO. For example, the second post in this thread by @richlander says:

we need […] usage data in order to help us find all of the rough edges

The telemetry feature is configurable, so you can turn it on/off at any time. It is also scoped, only applying to tools usage, not the rest of the product. We think that this is a good trade-off and recognize that not everyone will like it.

[rafaelrpinto]

@svick
I don't see it that way, on the contrary, I believe that was just the beginning of the discussion. Since the initial post the matter evolved to the current suggestion of an opt in approach which hasn't been formally ruled out so far.

Besides that the issue is still open, which make me believe there is still room for discussion.

[rustybox]

we need […] usage data in order to help us find all of the rough edges

Thank you for installing dotnet core.
Your usage can give us insight to rough edges where we need to make improvements.
If you are willing please hit Y to enable telemetry you can read more about it at {{url}}.

Otherwise hit any key to continue without telemtry

>

It's not Microsoft want telemetry that's the problem, I'm sure many people would be happy to share, it's the way it's being done.

[richlander]

See my recent post -> What we’ve learned from .NET Core SDK Telemetry. I see it is linked above, too.

I would be happy to entertain more opt-out options along the lines of https://github.com/dotnet/cli/issues/6086. I'm going to focus on that. The current model of telemetry is very useful given the usefulness of the data that it produces (as discussed in the blog post). It is very important for our future development that we continue to have access to the data.

I'm closing this issue. We've heard that feedback and are choosing to continue with the same model. I know that's a disappointment to the folks on the thread (and others). We're focussed on building a great application platform and are choosing to make usage data a very key part of that effort.

Full disclosure: dotnet/cli#7283

[kspeakman]

Thanks for all the fish.

[chrisjsmith]

And thus ends 15 years of .Net and C# for me.

[OpinionatedGeek]

Microsoft has talked a lot about its commitment to 'community' with open-source dotnet, but the truth seems apparent now: the community didn't ask for this change, this Issue shows many in the community don't want this change, and Microsoft say they're going to ignore that and do as they please.

I'm not so much disappointed in the decision as in Microsoft itself. I did think they'd changed when they open-sourced .Net and were honestly going to be community-driven. Apparently not.

[chrisjsmith]

Talk about community and commitment merely appears to be cheap marketing. Did we expect more? Really, the only motivation to open source .Net, move SQL Server to Linux and introduce WSL is to confuse the lines between disparate platforms to leverage sales of a subscription model. I was just hoping to take something away from this which I have invested years of my life in; clearly not. Alas that's a discussion for HN rather than here so I'm going to leave it at that.

[hardhub]

And thus ends 15 years of .Net and C# for me.

Maybe it is time to think about fork?
I thought about Java but it is not an alternative as well...
So we can just remove telemetry and create alternative distribution.. what do you think?

[rafaelrpinto]

I was getting interested on this Microsoft movement to Linux and open source, but now it's clear how things will ever be around here.

@hardhub
Between Scala, Node.js or Go there is certainly an alternative for what you need. The only thing .NET does better than all these other platforms is to collect telemetry =]

Cheers,

[hardhub]

@rafaelrpinto

Sorry bro but no...

Scala is totally Java dependent.. So why do we need Scala if we cannot accept Java?
If can accept Java then Java is very good alternative for .Net.

Node.js is absolutely not alternative... due to JavaScript, performance and absence of multithreading.

Go? Why not Rust then? Rust is C-like and designed to be amazing fast. But I think both have small popularity in community. So they have much less frameworks, community support and so on...

[rafaelrpinto]

@hardhub
JavaScript performance and absence of multi-threading?

Good luck with .NET bro. It's the right platform for you.

[dori4n]

@richlander: I'm closing this issue. We've heard that feedback and are choosing to continue with the same model.

I would like to point out, that, without informed, prior consent, collecting any personal information is illegal in most jurisdictions. There is sufficient precedent in the EU data protection directives 1995/46/EC, now superseded by 2016/679/EC, as well as similar legislation in the state of New York (not sure which one at the moment) that collection of any data amounts to collection of personally identifiable information, as the time the data is collected and the information about where on the internet it is sent from can often, though sometimes inaccurately, identify a person, and is often treated as such information.
The only way you can comply with the legislation is to ensure every user of your software is prompted and asked for consent (which you cannot reliably do, as computers may be in shared use in a manner that should be obvious to you) or to make telemetry collection an opt-in setting as specified in pulls dotnet/cli#7096 and dotnet/cli#7098 .
Yes, I understand this means you will most likely not get any or poor telemetry results. You are going to have to live with that, or stop distributing your software in the aforementioned markets. Blocking telemetry requests on a geoIP basis on your servers does not meet the requirement.
Feel free to contact the legal department. You may be liable for damages.

[ibqn]

This telemetry prompts are so badly implemented that they break the package installation on debian/ubuntu cp. dotnet/cli#7420

[chrisjsmith]

This demonstrates my point about testing above as well.

If MSFT don't back down then it's clear the community doesn't matter.

[inoperable]

That there even is a discussion about default opt-out is ridicule- and I'm pretty sure that the way telemetry is handled now (on by default) is illegal within the EU. Like some people already pointed out- this should be off by default, and there should be a simple option (see Homebrew, Yo) to disable it and not dig for information within git issues, and...

How about you telemeter this facts and stop spin-doctoring around angry users comments, and do something and not try to justify something (that your employee might enforce)

If I wouldn't read that small opt-out word after installation on macOS I wouldn't even know that you have and will gather any data at all, I can't say that this is obvious and well communicated fact - or is it? Really, I thought that MS Steve 'Monkey-boy' Ballmer era is gone and 2 words OSS and MS won't auto-generate jokes around the dev's table - but here I am again, feeling like it's 2001.

[inoperable]

Just read the telemetry page on dotnet, following the thought process there (and here to a extent),
I hope that every Linux distribution will automatically set DOTNET_CLI_TELEMETRY_OPTOUT=1 environment variable system-wide within /etc

[inoperable]

Btw. your installation script is sending telemetry - before displaying any information about the same step and not as you claim here since your installer launches the dotnet command itself and the very first thing it does, guess what? It phones home with telemetery (and /dev/nulling the thing itself)! For real?

pkginstaller cmd:

dotnet exec $INSTALL_DESTINATION/sdk/2.0.0/dotnet.dll internal-reportinstallsuccess "$1" > /dev/null

launching the same command from term without passing $1

System.InvalidOperationException: Sequence contains no elements
   at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source)
   at Microsoft.DotNet.Cli.InternalReportinstallsuccess.ProcessInputAndSendTelemetry(String[] args, ITelemetry telemetry)
   at Microsoft.DotNet.Cli.InternalReportinstallsuccess.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Uhmm... ok.

[realityexists]

I hope that every Linux distribution will automatically set DOTNET_CLI_TELEMETRY_OPTOUT=1 environment variable system-wide

@jankun I've raised an issue about this for my Linux distro (Linux Mint): https://bugs.launchpad.net/linuxmint/+bug/1720110 and I hope others do the same

[chrisjsmith]

Good idea.

More deafening silence from MSFT even though the telemetry is flawed as outlined by @jankun

[dazinator]

@chrisjsmith @jankun
I know this issue is closed but it's quite an interesting topic so just wanted to leave some feedback.
I agree that there should be a checkbox on the installer.
The only reason not to have a checkbox on the installer (or any other kind of Yes/no experience), is because _it makes it too easy_ for users to express a desire to opt out. You want to make this difficult, right?. Even if its a small step to go and set an environment variable - 'it's still a step!'. This will mean you still get the data for the portion of people who are too lazy or simply forget to follow up and set that environment variable. That's _more data for you_.

Also we are trained these days to bypass lots of boring text, and look for the things that we need to engage with on forms. When running through an installer - does anyone actually read the end user licence agreement in it's entirety? Ofcourse not! We have been trained to scan for the UI elements that actually require engagement of some kind. So:

• A bit of text explaining some stuff about telemetry - meh - not important - you can't change this text or have any impact on it right now.
• A checkbox confirming whether I want telemetry enabled? Ok thats actually engaging me with a question. I'll respond.

Microsoft don't want to truly engage you with this question - they need this data. This data makes the product better. That means _they don't really want you to have a choice_.

It's a shame because when users are given a choice, and they do choose to help improve a product - you garner loyalty from that user at the same time. The user, feels like they chose to help the product and this in turn makes them feel valued - which builds trust, and loyalty. The question may as well ask "Do you trust me?". Microsoft are too scared to ask such a question - they would rather you didn't even think about this question - just focus on the goodies that come in each new release.

Can we blame them? Well we can stop using their product. Thing is dotnet core is absolutely fantastic and this isn't a sacrifice I am willing to make for the sake of what is actually being collected. It's a trade off. I am forced to accept a seemingly underhanded way of collecting data just because the platform _is something I want to use._. Their licence is pretty clear on the topic:

License
The Microsoft distribution of .NET Core is licensed with the MICROSOFT .NET LIBRARY EULA. This license includes the "DATA" section to enable telemetry (shown below).
.NET NuGet packages use the same license but don't enable telemetry (see Scope).
DATA. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to improve our products and services. You can learn more about data collection and use in the help documentation and the privacy statement at http://go.microsoft.com/fwlink/?LinkId=528096. Your use of the software operates as your consent to these practices.

Given that the installer records telemetry on install though - it's arguable whether you can "use the software" (and thus consent to telemetry) before it's actually installed. So sending telemetry on install seems a bit shady - depending on whether that classes as actually having used the software yet.. I imagine that "use" the software means as soon as you launch the installer, not as soon as you run your first dotnet cli command. In which case, the installer can send whatever telemetry home it likes, before you are even aware of it, let alone before you decide to disable it.

[chrisjsmith]

It's very shady and the reason it's shady is because no one gives a crap if they get their data, thus proving again that the customer, even if paying like my good self, comes second.

The problem is not that there should be a check box in the installer. It is that the default assumption should benefit the user before the vendor, particularly as this is supposed to be a _good citizen_ open source project. In this case, the telemetry should default to OFF to protect the user's privacy. It should ask to enable it. This applies particularly to the scenarios where it isn't deployed on top of windows and is instead deployed from package repositories on Linux distributions. If you look at the common ecosystems around Debian for example you will not find telemetry enabled by default anywhere. In fact you will see a very strong pro-privacy stance.

Personally, I really don't care if the data benefits Microsoft. It's whether or not the collection benefits me and it does not. There are far better ways to engage the customer and take feedback. Like not letting things sit on MS connect for 5 years unfixed, being able to coordinate between the dotnet and clickonce team on critical issues that crippled us for years, actively listening to customer requests on privacy rather than deafening silence while at the same time trying to drown everyone in blogs, marketing etc. Or perhaps fix some well recorded bugs where the start menu stops responding to the keyboard in Windows 10 that has been floating around for 2 years. None of these things get fixed with data; only customer engagement and not the lip service of blog posts, uservoice and other ridiculous abstractions to try and hide the incompetence.

This is merely a growing abusive relationship with a rather regressive, data-obsessed corporate America and I'm out. There are better options on the table.

If you want an illustration of how much data is being collected, install Fiddler on your PC and let it run for a couple of hours. I personally, and many of us, don't want this to be a de facto standard for software going forwards.

[omajid]

This applies particularly to the scenarios where it isn't deployed on top of windows and is instead deployed from package repositories on Linux distributions.

To be fair, most Linux distributions compile software from source. If they were building .NET Core and packaging it, they could just disable telemetry by default.

[hardhub]

@omajid

To be fair, most Linux distributions compile software from source. If they were building .NET Core and packaging it, they could just disable telemetry by default.

I do not agree. Maybe RHEL will do that and maybe CentOS maintainers (in the future) will include own packages in their repositories (with telemetry disabled?).
In any case current official documentation from MS says the following about CentOS:

And obviously this package contains original version with telemetry.

There is same situation with Debian.. just look it here for more details:
https://www.microsoft.com/net/core#linuxcentos
https://www.microsoft.com/net/core#linuxdebian

[omajid]

Maybe RHEL will do that and maybe CentOS maintainers (in the future) will include own packages in their repositories (with telemetry disabled?).

RHEL already does. I am working with CentOS folks to make that happen too (with telemetry disabled by default).

And obviously this package contains original version with telemetry.

Yes, that is true. Sorry, I didn't mean to disagree with anyone here. I was speaking about a hypothetical future where .NET Core was built by and part of Linux distributions. I know that this is not the case right now and the packages published by Microsoft do not meet the packaging guidelines (including collection of user data) expected by many Linux distributions.

But if .NET Core was packaged into Debian (not just for Debian), it would have to comply with packaging standards that Debian uses. And so it probably would have been patched to not collect user information by default.

[realityexists]

RHEL already does. I am working with CentOS folks to make that happen too (with telemetry disabled by default).

That's great to hear! I hope it also happens for Debian and Ubuntu and all their derivatives.

[kstarikov]

RHEL already does

Does it also disable the telemetry during installation that is independent to runs before the message about DOTNET_CLI_TELEMETRY_OPTOUT?

[benaadams]

Does it also disable the telemetry during installation that is independent to DOTNET_CLI_TELEMETRY_OPTOUT?

Telemetry is disabled in every situation, including installation if the DOTNET_CLI_TELEMETRY_OPTOUT flag is set, as in the source for the Telemetry.cs component

[hardhub]

I was speaking about a hypothetical future where .NET Core was built by and part of Linux distributions.

It is what I mentioned...
For now any regular user without enough background is affected.
Of course I agree the future can be better than nowadays :)

I am working with CentOS folks to make that happen too (with telemetry disabled by default).

Thanks for that!

In any case I think @kstarikov has asked interesting question.

[chrisjsmith]

@benaadams I'm getting a bit tired of the parroting of MVPs. If you say something over and over and over that doesn't change the point. Seeing as we're verging on the ridiculous evasion of the problem, lets throw a ridiculous analogy at the wall:

This is like walking into a public toilet and being mugged because I didn't write a magic symbol on the wall in one of the cubicles. Look at the problems with this:

1. I'm being mugged before I get the opportunity to write the magic symbol.
2. No one, apart from perhaps in Harry Potter, wants to spent the entire day working out random things to write on the toilet wall.
3. I'm being mugged to start with when every other public toilet is safe to enter.
4. The owner of the public toilets is quite happy because he's keeping all the wallets and phones.

This is a typical example of MSFT's design policy which is fundamentally: stupid defaults and lots of static state.

I've had enough now.

[svick]

@chrisjsmith Someone (@kstarikov) asked a question, @benaadams provided an answer (AFAICT an accurate one). That's it.

Sure, if you fundamentally disagree with the whole thing, discussion about its technical details is probably irrelevant to you. But that doesn't mean others can't have that discussion or that if they do, they are somehow "evading".

[omajid]

That's great to hear! I hope it also happens for Debian and Ubuntu and all their derivatives.

Please get involved and ask others from Debian and Ubuntu to get involved in https://github.com/dotnet/source-build/. This is where the work for building .NET Core from source for packaging is taking place.

RHEL already does

Does it also disable the telemetry during installation that is independent to DOTNET_CLI_TELEMETRY_OPTOUT?

We dont call any dotnet commands in our installation package steps (https://git.centos.org/blob/rpms!rh-dotnet20-dotnet.git/c7-dotnet/SPECS!dotnet.spec). It just copies files around.

[kstarikov]

I guess the issue mentioned here for the OS X postinstall script is that is runs the internal-reportinstallsuccess dotnet command, which sends telemetry before showing the user the message about DOTNET_CLI_TELEMETRY_OPTOUT.

[sushihangover]

FYI: Microsoft

The fact that this is an opt-out vs. opt-in and the opt-out procedure is based upon an env. var. just caused dotnet to fail an externally conducted HIPAA privacy/security audit at a genome testing lab in the backyard of your main campus.

Lucky for us, we were able to convert the runtime to use Mono and get a temporary pass, but this killed the future CIL-based projects with the lab's management...

[chrisjsmith]

@sushihangover this is exactly what I was whining about earlier. There are security policies that this will violate simply for existing.

Now you already screwed windows phone into the ground, let's not do the same with the CLR. It's not like I didn't invest 15 years of my life in the product...

[nathan-alden-inl]

@chrisjsmith I appreciate your passion. I just read your comment on HN and wanted to say I'm equally frustrated about this decisions and others like this. Microsoft, we're talking about _command-line tooling for an application stack_. There is simply no excuse for this decision. Adopt a policy consistent with how other major vendors like Mozilla expose data collection: opt in only.

As a matter of principle, I've now updated my developer workstation configuration guidelines to require DOTNET_CLI_TELEMETRY_OPTOUT to be set to 1. I've also updated my Cloud Foundry manifests to set it. In addition, I've opened a GitHub issue that asks the Cloud Foundry devs to ensure this environment variable is set for all uses of the .NET Core buildpack.

[voronoipotato]

Microsoft let the train go off the rails again in open source. Their understanding of consent, dialogue, and community really needs to develop or nobody is going to want to work with them. They're going to see Microsoft as the place who can't even cope with free labor.

[jtsagata]

Is there any good fork out there without this crap ?

[sushihangover]

@richlander @terrajobst @migueldeicaza

As a followup to my last post, got the word today that since the dotnet runtime will not allowed to be used in production, the Xamarin.iOS associated project is also dead as any C#/F# code sharing with the backend is now gone.

This was a 25K participant (patients/researchers/doctors) Apple HealthKit/ResearchKit/CareKit Xamarin.iOS app (iPad Pro dashboard for researchers & doctors, iPhone and A-Watch for patients). Killed due to opt-out telemetry that should not exist in the first place, my head is still spinning...

[benaadams]

since the dotnet runtime will not allowed to be used in production,

Build (publish command) a standalone/self-contained app (which the dotnet cli allows you to do) with your dev or build server, then you don't even need the dotnet cli installed on you production machines and there is no telemetry to opt out of

From Self-contained deployments (SCD)

Why deploy a self-contained deployment?

Deploying a Self-contained deployment has two major advantages:

• You have sole control of the version of .NET Core that is deployed with your app. .NET Core can be serviced only by you.
• You can be assured that the target system can run your .NET Core app, since you're providing the version of .NET Core that it will run on.

It also has a number of disadvantages:

• Because .NET Core is included in your deployment package, you must select the target platforms for which you build deployment packages in advance.
• The size of your deployment package is relatively large, since you have to include .NET Core as well as your app and its third-party dependencies.
• Deploying numerous self-contained .NET Core apps to a system can consume significant amounts of disk space, since each app duplicates .NET Core files.

[sushihangover]

@benaadams Thanks for the reply, but a static publish does nothing for this project as the F# genome models are dynamically created/compiled based upon the researchers and doctors queries against the patient's records.

They are taking TBs of graph structured data and morphing it into mobile friendly data that can be visualized "on-the-fly", the genetic researchers have designed/modeled this data and changing that would require a multi-year cycle of government and independent reviews/audits. Even the pre-teen patients get their private data transformed by the same dynamic models into a SpriteKit-based "game" with health goals that are monitored by the parents and doctors.

[raymondSeger]

@ghost You just said what everyone else are thinking.

@chrisjsmith thumbs up

Why would you need to track these kind of data in the first place? Privacy is important to your customers you know!

[hardhub]

@sushihangover

Can you explain about Xamarin iOS?
Does it have any telemetry as well?
Or is it due to integration and code-base sharing?

[sushihangover]

@hardhub In terms of Xamarin, it is due to integration and code-sharing only.

Code-sharing was why a Microsoft stack was considered in the first place, each code module (and resulting assembly in this case) has a massive HIPAA, data accuracy, security, etc.. review and audit process attached to it so "code-sharing" between a dotnet backend and a Xamarin-based mobile solution would have saved about $400k on the project for the first year and another ~$200k per year after that (this post-rollout saving could vary be as much as +/-50% depending upon model/code changes). (This saving is only the review/audit saving, the saving on coding hours was about 2X as over 5000 man-hours was to be saved)

FYI: Xamarin does use telemetry (i.e mono-sgen64 calls out to api.mixpanel.com) but this telemetry is not within any Xamarin.iOS / Xamarin.Android runtime.

[MaikuMori]

I would assume that Microsoft uses .NET Core in their own projects. This should create enough data so that it's not needed to track normal users. At least it would make sense to have opt-in instead of opt-out.

[hardhub]

@sushihangover

Xamarin does use telemetry (i.e mono-sgen64 calls out to api.mixpanel.com)

Not sure I understand all exactly... What does "Xamarin" mean here?
All Xamarin mobile runtimes do not have telemetry (that you said) and SGen is garbage collector that is implemented for Mono. And you have used Mono to pass audit... hmm.

[sushihangover]

@hardhub Sorry about the confusion (I updated my comment).

mono-sgen64 via Visual Studio calls out to api.mixpanel.com

[chrisjsmith]

Can we stop the language games, the different configurations and madness and uncertainty around which bits of the CLR we are using. We’re not lawyers and don’t want to be.

Just remove it.

[svick]

@sushihangover

a static publish does nothing for this project as the F# genome models are dynamically created/compiled based upon the researchers and doctors queries against the patient's records

Do you actually need the .Net Core CLI for that? If you directly used the F# compiler and possibly MSBuild to compile the models, then I believe there wouldn't be any telemetry.

[emente]

Opt-In or complete removal.

Everything else is unacceptable.

[4creators]

Telemetry issue is becoming really very serious once you get with your project into any kind of protected data. Just receiving IP of machines on which CLI is running violates privacy rules as IP is regarded in most EU countries as personal data - it may allow identification of an individual. Obviously one may turn it off after install but since it is set to on during install by default it violates active opt in rules.

During installation information on CLI telemetry is presented to users but it is not enough according to European Union regulations. If someone wants to collect any sort of data which is not related to basic functionality of provided software it is required by law to present to user active opt in choice with default setting during user interaction being opt-out. So no action from user always means "no telemetry allowed". This endorses rule of conscious user consent made after presenting unequivocal choice with default choice being no consent from user.

Microsoft entirely unnecessary exposes itself to legal risks at least in all EU jurisdictions ... fact that nothing happened in this area so far is no guarantee that it will not happen in future. Just learn from Facebook problems ....

Please take it as a very friendly comment ... like many others in this thread I have invested years in MSFT technologies and would like to see them succeed.

[4creators]

There is an important from the perspective of this thread issue What is the expected usage of source-built assets? in dotnet/source-build repo which indicates that it will be possible to build every non MSFT distro entirely from source (no binary blobs even for tools) and it will be possible to patch offline builds which otherwise should be binary compatible with MSFT build. This may solve issue of telemetry in general as it can be removed from CLI code.

[b3nt0]

Maybe what MS should do is build a telemetry manager that all of their tools plug into. Then users would have a central place to opt-in or out of telemetry collection for an entire system.

The people complaining about this are probably the same people complaining about telemetry collection in every product that performs that function. If you centralize it, provide a way for people to inspect what is being sent back, and give it a big "OFF" switch, you could turn this whole story around.

It would probably also be a good idea to have a telemetry manager to control and protect the server end points that are taking data. Right now every team at MS is rolling their own system for collecting the data. Someone will end up getting that wrong and there will be a data breach. Formalizing your approach to collecting data on the "client" and sending to back end systems for reporting will protect MS as well as other entities.

How do you do that on Linux? That's really touchy. You could work with the distro vendors, and start an OSS project for the telemetry manager component. In the end, you are probably only going to be able to collect telemetry if you are VERY explicit about it during install on Linux systems. The overlap of privacy maximalists and Linux users is much higher than with Windows.

It's just going to keep coming up, and the "we told you so" moment is coming. You only have to get it wrong once.

[migueldeicaza]

Mhm I have never heard of mono-sgen64 calling mixpanel. This must be some third party library, not the runtime.

Got some repro step that shows this?

[realityexists]

@b3nt0 Even if Microsoft implements a tool they can re-use to collect telemetry data across all products, I just don't see them building a client tool that makes it easy for the user to opt out for the simple reason that it's not in Microsoft's interest to do so. It's in their interest to make it possible to opt out, so the product can be used even in scenarios where telemetry is unacceptable, but it's not in their interest to make it easy.

[markrendle]

I'm working on a project related this sort of thing (not .NET specific), and I wondered if the more vocal anti-telemetry posters in this thread could maybe explain to me exactly what concerns them about this type of telemetry collection.

Genuine question, and no personally identifiable data will be collected :wink:

[nathan-alden-inl]

It's not the telemetry itself, it's:

1. the default being opt-out, not opt-in.
2. their stubbornness against making it opt-in.
3. their attempts to disguise their true motives.

I think some people are simply making a stand against data collection because it seems corporate culture is hellbent on it at all costs. There's a bigger battle being fought, and this is just one skirmish on the edge of that battle.

[cznic]

Genuine question, and no personally identifiable data will be collected :wink:

Because telemetry always collects personal data, unless it calls "home" through some IP anonymizer service, which I doubt is the case.

Disclaimer: I don't use, nor I think I ever will, any MS SW. This thread shows just one of the reasons.

Disclaimer2: I do allow opt-in telemetry by some companies I _do_ trust, when they ask nicely for my opt-in and I think it can be indirectly helpful also for myself.

[markrendle]

@nathan-alden-inl But there is obviously some underlying "telemetry considered harmful" attitude, otherwise there would be no problem with it being on by default. There are plenty of things in life that are on-by-default but can be turned off - like the Electronic Stability Control in my car. I'm interested in what people consider to be so bad about seemingly innocuous telemetry that mean it should be opt-in.

[markrendle]

@cznic Why do you have a problem with your IP address being collected? Do you have a problem with it being attached to all your posts in this thread?

[cznic]

Why do you have a problem with your IP address being collected? Do you have a problem with it being attached to all your posts in this thread?

No, why I should? And if I would have a problem with it, I would hide it.

It depends on what one is doing and who collects the data. Especially the later is significant. I share much more than just an IP on Github, they also have my credit card info, for example. I consider Github trustworthy, no bad record I know of. MS? Not so much. (OK, TBH, %0 trustwothiness in my personal opinion.)

[dotaheor]

@markrendle
it is simple. dotnet cli telemetry collects data I'm not aware of, but I'm aware of a client-server app will get my ip.
I HAVE TO provide my ip to use a client-server app, otherwise I can't use the client-server app.
However, it is TOTALLY NOT essential to provide my ip to dotnet cli.

And I don't consider telemetry harmful, I just think telemetry should respect users.

[markrendle]

@dotaheor What is wrong with a server getting your IP address?

[dotaheor]

@markrendle it is no problem for a server to get my ip. It is just that the server should let me be aware of it gets my ip.

[markrendle]

@cznic So for you it is important to easily determine who may and may not collect data at a "corporate entity" level?

[markrendle]

@dotaheor So if the data could be sent in a way which did not reveal your IP address to the telemeter, you wouldn't mind?

[cznic]

So for you it is important to easily determine who may and may not collect data at a "corporate entity" level?

I see where are you trying to lead me ;-)

Recent illustration: https://betanews.com/2017/10/09/cortana-skype/

[migueldeicaza]

I looked into this, it is not mono-sgen64 that is calling into MixPanel, it is Visual Studio for Mac that does. To disable this, go into Preferences -> Other -> Feedback and click to disable the option.

[dotaheor]

@markrendle

So if the data could be sent in a way which did not reveal your IP address to the telemeter, you wouldn't mind?

You must be kidding. Here is the "ip" we are talking about is just an example of some private data.

[markrendle]

@cznic Not trying to lead you anywhere, just doing some research. Thank you for your answers, very helpful.

[dotaheor]

@markrendle
to state it again. I don't care about my private data is collected, but I must be aware of what of my private data is collected and how it is collected.

[markrendle]

@dotaheor OK, thanks, I think I get where you're coming from.

[jkoberg]

@markrendle did you miss the comments from the poster who's .net-based work in a HIPPA (US health privacy law) regulated project is now cancelled, because they can't permit tools that call home?

"I can't think of why it might be bad" is not a sufficient reason; it's an argument from ignorance. Trust that it takes the tool out of consideration in high-security environments, and not for personal/moral reasons.

[markrendle]

@jkoberg I saw them; I'm currently working in a finance org where the proxy blocks calls to a lot of telemetry servers (and many others: e.g. I can't install VS Code extensions through the application itself) for similar reasons. I appreciate that there are environments where any leakage of any data is in violation of regulations, and that demands something other than an opt-in/opt-out preference offered to users at installation time. It's also why the SDK collects telemetry, but the runtime-only dotnet that is to be deployed into production environments does not; production systems obviously need to be much more locked down than developer workstations.

My interest is in the individuals who instinctively resent the collection of what many would consider to be harmless and potentially beneficial telemetry data from their own environments.

[svick]

@dotaheor Do you find the notice that's shown in the installer and before the first dotnet command is run insufficient? If so, what else can be done to make you better aware of it?

[dotaheor]

@svick
for me, it is not a big problem, for I will set the DOTNET_CLI_TELEMETRY_OPTOUT anyway.

However, this project should state a requirement in the license to third-party tools which includes the cli that the tools must also present the notice you mentioned to users.

Besides the above point, I think the data list below which will be collected by this cli is unnecessary and unpleasant:

• Hashed MAC address: a cryptographically (SHA256) anonymous and unique ID for a machine. This metric is not published.
• Hashed current working directory.

[iigorr]

The topic is trending on hacker news right now. https://news.ycombinator.com/item?id=15439001
Stupid decisions which ruin great projects... great job.

[benaadams]

My understanding, from reading the source, of what is happening

The runtime itself does not send telemetry so you shouldn't be sending any in telemetry production regardless of the environment setting by using the runtime package and running your pre-built app with the shared runtime by doing:

dotnet my.dll

This is also confirmed as the intention from the documentation

Telemetry isn't enabled when using the dotnet command itself, with no command attached:

• dotnet
• dotnet [path-to-app]

Equally a self-contained deployment will produce an executable file that requires nothing to be installed on the target machine and will not send any telemetry when running that executable.

The sdk does send telemetry; this is also confirmed as the intention from the documentation

Telemetry is enabled when using the .NET Core CLI commands, such as:

• dotnet build
• dotnet pack
• dotnet restore
• dotnet run

The first install/run at command line that prints the message about DOTNET_CLI_TELEMETRY_OPTOUT uses the FirstTimeUseNoticeSentinel which does not send any telemetry if it also is printing the message; so you are warned prior to it sending telemetry.

It does not send any telemetry after that if the DOTNET_CLI_TELEMETRY_OPTOUT set to one of true, 1, yes (case insensitive)

The HIPAA example @sushihangover gave compiles programs in production so it is using the full sdk rather than just the runtime.

The workarounds to the telemetry when using the sdk (build/run etc) as I understand them are:

• either, set DOTNET_CLI_TELEMETRY_OPTOUT environment variable
• or, use MsBuild rather than dotnet to build your app - its what dotnet ends up calling and it doesn't send telemetry - its also less convenient; but what you'd probably be using on your build server

Not sure what the Windows desktop installer does first time; there is a IsDotnetBeingInvokedFromNativeInstaller path which does something different

tl;dr

If you receive the message

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

Telemetry
`---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

That use will not report any telemetry; but it will add a local sentinel file to mark that it has warned you

Running your app directly will not send any telemetry e.g.

dotnet [path-to-app] rather than doing dotnet run

This is what you should be doing, generally, in production anyway, rather than using the sdk commands

[dotaheor]

@benaadams can you make sure that set the environment will take effect for the current opened terminal session or not?

In my honest opinion, when first time run the cli, the cli should present a [Y/n] choice to user,
instead of letting users to set an environment. If you let you set an environment, the environment
will only take effect from the next time a terminal is opened.

And the user choice should be saved in .dotnet.conf alike file instead.
The .dotnet.conf file should the same file saved the info of whether or not user has made a choice.
Later, user may delete the environment but the .dotnet.conf file may still record that user has made a choice.

[benaadams]

@dotaheor
for bash in linux for current session
export DOTNET_CLI_TELEMETRY_OPTOUT="1"
and add same line to
~/.bashrc
for future sessions; or whatever's appropriate for shell you use
~/.profile for terminals on Ubuntu desktop or equivalent for your distro

Windows cmd
Current session
set DOTNET_CLI_TELEMETRY_OPTOUT=1
Future sessions
This PC -> Properties -> Advanced -> Environment Variables -> New User variable (Or System Variable)
Or IT admin via group policies etc

Don't know how macOS works

I assume environment variables are an easy thing to explain and get working cross platform. User home directory is more complex to explain cross platform - could always do both though

[dotaheor]

@benaadams

for bash in linux for current session

export DOTNET_CLI_TELEMETRY_OPTOUT="1"
and add same line to
~/.bashrc
for future sessions; or whatever's appropriate for shell you use
~/.profile for terminals on Ubuntu desktop or equivalent for your distro

I know this. But this doesn't take effect for the already opened terminals.

I assume environment variables are an easy thing to explain and get working cross platform. User home directory is more complex to explain cross platform - could always do both though

There is already a file for saving the info of whether or not user has made a choice.
So it is not a bad idea to also save user choice there.

[kspeakman]

@markrendle I have a question for you. MS used to have opt-in telemetry for nearly all products. But in the last years has switched to opt-out for basically everything. Why?

You should also review the whole thread for other reasons why people don't like opt-out. It's like taking pictures and video of me and my home without asking. It's like reading someone's text messages over their shoulder. It's creepy. And your promise of how the info is used today means nothing tomorrow.

[kstarikov]

I don't think I'll be able to use .NET Core at work until telemetry becomes opt-in.

[oaiey]

Thanks @benaadams for the audit.

Regards the HIPAA violation of @sushihangover: I work for a healthcare business. We have 5-7 development stacks, one of them .NET Core. This issue is mitigated very easy and would never give us any troubles.
If the customer jumps off a platform that easy he either does not understand much about software engineering, is ill advised or (worst case) has no idea about how to run a business in a regulated environment.

[cznic]

If the customer jumps off a platform that easy he either does not understand much about software engineering, is ill advised or (worst case) has no idea about how to run a business in a regulated environment.

If a customer jumps on a spyware infested platform that easy she either does not understand much about software engineering, is ill advised or (worst case) has no idea about how to run a business in a regulated environment.

[voronoipotato]

Let's be clear it's an obvious breach of trust, and anyone working in environments with sensitive data should avoid dotnet core arguably indefinitely. @oaiey it is better to be safe than to be sorry, i'm glad you trust microsoft with your wellbeing but I can't always read every check in to make sure they aren't sliding in telemetry that likely increases the attack surface.

@kstarikov Same, and I'm glad I had only played with it at home.

[voronoipotato]

@markrendle "But there is obviously some underlying "telemetry considered harmful" attitude, otherwise there would be no problem with it being on by default."

You have a clear issue understanding consent. Forcing me to drink tea, or trying to pour it in my mouth when I'm sleeping does not mean I object to tea. It means I object to microsoft being slimy and creepy around consent and I will use other products/vendors when they do this. The difference between this and say traction control in a car is it's something I have, that you want. If you want something you have to ask for it, you don't get to just take it.

[migueldeicaza]

@sushihangover On MixPanel, we looked into this, and while we used it a few years ago, we do not see traces of it on the source code, or the binaries. We are puzzled as to where this might be coming from, and wondering if perhaps you have some third-party add-ins installed, or some external tool and perhaps those are using it?

Would love to know how you triggered this.

[svick]

@voronoipotato

When you go to a concert, do you have to consent to being recorded by a clearly visible camera as a face in the crowd? I think the situation here is similar to that.

You can decide that this kind of recording of your actions is not okay for you and not use a product that does it. But I don't think it's as black & white as you make it sound, that it's Microsoft taking something from you without your consent.

[hardhub]

Hashed MAC address: a cryptographically (SHA256) anonymous and unique ID for a machine. This metric is not published.

And how much minutes is it needed to create table for MAC or IPv4 addresses (which are mostly used everywhere.. 80% of all internet users)?

Three octet IP address used to determine geographical location†

It is enough to get subnet... and then target machine with help of MAC...

Microsoft is kidding us... :)

When you go to a concert, do you have to consent to being recorded by a clearly visible camera as a face in the crowd?

You can compare concert and platform which will be invested in millions/billions dollars worldwide by software developers and different product vendors... hmm.

I think when you are on concert you know where you are... even when you are in the street you know where you are. And I personally do not like that.. but it happens.. look here:

https://www.youtube.com/watch?v=Doqg1eCQieo

But .net core is a tool... and even a small breach of privacy is a drawback of this tool. It is just fact.
What do you want to say by your posts? Privacy is not important? I have different opinion and big data examples confirm my thoughts very good.

[oaiey]

@voronoipotato trust is a valid point. However, I trust their commercial interest a lot that they do not do bullshit. A serious HIPAA violation would be e.g. access to patient data. But we are not talking about that here.

Also regards trust: whom should I trust? The Node platform with npm and their packages with anonymous author and missing public repos? The Java platform with their installer? That leaves C++ and doing everything on my own with high costs. But that is financially not reasonable for e.g. a genome analyzer. For a insulin pump, yes.

It is not about trust. It is about being unprofessional and delivering without knowing what you deliver. In the current of state the telemetry in .NET Core SDK is well known and understood.

[ghost]

So, it is the case that after a year+ of this going on, that literally nothing of substantive has come from gathering this telemetry (go ahead and argue with me on that one, but I will vehemently disagree and preemptively argue that you are just adorning something useless with bells; polishing a turd, if you will). I think it is time for it to go as it is just a leveraging point against dotnet, and does nothing to accomplish the real objective: wide-spread adoption of the CLI. In fact, it can be argued that it is now inhibiting this outcome.

Maybe other CLIs do it, and maybe there is a vibe of irrationality with regards to the arguments waiving the banner of privacy (and we know Microsoft is not a big fan of privacy, if you want this opinion to change then demonstration by action is a great move), but no matter: It isn't actually accomplishing anything other than to distract people from real discussions about real possible features for the dotnet CLI. Or maybe that is the objective in itself: No such thing as bad press? That's just stupid PR if that's the case. Unless the objective is to lower your public perception so much so that no matter what step you take next there is only up; this is also a pretty distressing idea to consider.

Anyways, if developers come to you with their opinions, you should be more than eager to oblige, and you should be operating from the perspective to adopt as many users as possible. Microsoft has not needed telemetry in the past to produce good products like Visual Studio (maybe I am wrong?) and so I struggle to see why you need it now. Good experiences are not built from telemetry, they are intuited by experienced designers or developed thoughtfully and iteratively. See the Tesla models, or the iPods, or even your very own Surface Book.

I don't generally think that telemetry is harmful, but in this instance I do believe that it is harmful to the perception of the CLI. Additionally, there are people literally telling you: "I wanted to use this, but I could not because of the telemetry feature"; what a stupid reason to lose a customer over. There are many different avenues customers can be driven through to attract the same information that is being gathered here, normally opt-in related which is actually what you want in your telemetry anyways. Because, lets be honest: you don't actually care about the normal behavior, you want to hear about the joy points, and the pain points, and such responses are only elicited in the extrema. So long as you facilitate the reporting of bugs (does the CLI gather bug reports?), or opinion (does the CLI have opinion gathering mechanisms?) or so long as you peruse the internet/read GitHub, you are going to be OK.

Maybe now is a good time to be reminded: You do not exist without your customers. Spend a few cycles building things that will cultivate trust and open communication. Think outside the box for a bit, the "me too" behaviors are disheartening.

[olejorgensen]

Windows 10 is the Miss Piggy Edition of Windows - under all that lipstick it's still just Windows. Kind of fitting that .NET Core also is the Miss Piggy Edition of .NET's

[chrisjsmith]

@oaiey I think the JVM is clearly the future. You don't need the Oracle installer. It's mature, cross platform, has a wealth of mature libraries, tools and integrations and the build and deployment infrastructure is done and dusted. You don't have to use Java if you don't want to either. It was the birth place of a lot of the design methodologies and bits of infrastructure that are crudely copied on the CLR.

I'm really wishing I took the blue pill back in 2002 and went down the Java route at this point. The red pill was a bad choice.

To be clear, a lot of people are looking at HIPAA compliance as "for use in medical devices". This isn't the case. PII and control of data is the problem. Telemetry is fundamentally incompatible with that as it decreases the signal-to-noise ratio.

Another analogy: You don't design a secure system with the starting point of a sieve and try and fill all the holes with environment variables. You start with something that is locked down and open what you need. The problem is that telemetry uses the same protocols and ports as the legitimate and controlled data which adds noise and risk because every communication needs to be understood. That control has to happen in every part of the environment from the workstations the developers use, through to the build infrastructure, through to the production environment. And that is why Windows 10 and this sudden increase in telemetry in developer tooling is an absolute nightmare for us.

[markrendle]

Interesting aside: I just installed Firefox Developer Edition, from noted privacy stalwarts Mozilla.

Here's the privacy notice you get when you first run it:

[markrendle]

Unrelated to my project research, but another thing occurred to me.

In the UK (where I live) we are changing to an opt-out model for organ donation. The rationale is that most people think that organ donation is a positive thing and are not opposed to it, but never get around to opting-in for it. By making it opt-out, the (estimated) minority who—for whatever reason—want to hold on to their organs after they die are able to make that choice, but most people won't do that and many lives will be saved as a result.

It's something that is being done for the good of the many, but still provides an opt-out mechanism for the few who are opposed to participating.

[kstarikov]

But it looks like 'few' prefer opt-out telemetry in dotnet while 'many' want it to be opt-in or nonexistent.

[markrendle]

@kstarikov Can you link me to your statistical source on that?

[dazinator]

Can you link me to your statistical source on that?

@markrendle - Perhaps Microsoft could gather some telemetry for you to use as a statistical source on this question. The installer and cli can have its message changed - "those that would prefer an opt-in for telemetry in future should add an environment variable 'I-PREFER-OPTIN' but leave telemetry enabled." Then the telemetry can call home with the value of that variable - and voilla you have a statistical source as to those users opposed :-)

[dazinator]

@markrendle - because the only answer for unknown questions is obviously more telemetry at this point :stuck_out_tongue:

[markrendle]

@dazinator I think they have, indirectly: the number of people using the dotnet SDK, minus the number of dissenters. Obviously that will not return a completely accurate number, since the subset of dissenters will probably have turned it off, so their numbers won't be included in the telemetry, but I'd hazard a guess that it would be within the margin of error anyway.

And I guess there's no way of telling how many people are actively refusing to engage with .NET Core at all because of this privacy issue, but again, margin of error.

[markrendle]

@kspeakman

I have a question for you. MS used to have opt-in telemetry for nearly all products. But in the last years has switched to opt-out for basically everything. Why?

They probably read Nudge, by newly-minted Nobel Laureate Richard H. Thaler.

[dazinator]

@markrendle - How do you indicate that you are a dissenter? Microsoft love environment variables for yes no questions, so I propose they stick to these now for consistency. Keep the users happy. I_AM_A_DISSENTER looks good to me.

[markrendle]

@dazinator You post in this issue or participate in HN threads.

[markrendle]

@dazinator My point being, the vast majority of people just don't care.

[dazinator]

@markrendle - I agree to a degree. The fact that most people are simply _compliant_ though, doesn't mean you can use them as statistical weight for the support of telemetry on by default. If you did the same analysis by looking at how many people posted on the original github issue for the telemetry feature in the first place, you will find that - most people _just don't care._ about telemetry full stop. If you were biased you would say that most people don't want any kind of telemetry at all. But I am not biased! (Although my intuition is that this would be closer to the truth)

So knowing that, _most people_ don't care about telemetry at all - you can't count these people to lend weight to one side _or the other_ - they are simply compliant with whatever path is carved out for them. This leaves you with only the carers! For me, it should be alarming for microsoft that there are so many people chiming in on this issue. Personally my own concerns would be placated with a simple checkbox on the dotnet cli installer. But I am not going to give up on the platform over this issue - I am not one of the unlucky developers who are purportedly losing contracts over this!

[rbq]

@ghost Thanks for bringing this up. I was actually tempted to give .NET a try before I read this.

[markrendle]

@dazinator I just think the absolute numbers for "the carers" are so vanishingly small compared to the overall numbers shown in the telemetry that, given the value the telemetry itself provides to the teams, it's deemed not to be an issue (pun intended).

If anybody wants to prove this wrong, and that a significant number of people really do care about this, then some sort of online petition might be the way to go.

[h3smith]

If that is your metric for "carers" then _no one cares about dotnet core_. This is one of the most commented on Issues in all of the dotnet repos (outside of the technical issues soliciting technical feedback), _it is the most commented issue_.

To say not enough people have engaged when it is clearly driving some of the most engagement is ignoring the issue because it isn't convenient.

[markrendle]

@h3smith To put this in perspective: 142 people have 👍 the opening comment in this issue.

The telemetry shows more than 150,000,000 data points regarding operating system version distribution, each of which represents a separate install, if not user.

[chrisjsmith]

Lots of people smoke. Look where that got us.

[h3smith]

So you are conflating people bringing up an issue with _automatically configured and enabled telemetry_ is less of an issue because of the number of metrics gathered by _automatically configured and enabled telemetry_?

I don't even know where to begin if that is the dismissive stance you take, because they have nothing to do with one another, other than it is on by default when installed and a user must be more than a novice to disable it and know that it happens.

[markrendle]

@h3smith I'm just suggesting that when fewer than one in every million users have enough of a problem with something to complain about it, that might not be as big a deal as a 170-comment GitHub issue participated in by a very specific type of user could make it seem.

[cznic]

Should it be tolerable if I steal something from fewer than one in every million or should I go to jail like any other thief?

[markrendle]

@cznic False analogy. When you steal something from someone, they don't have it anymore.

Counter-analogy: if 250 Americans think a law is unjust, should the United States federal government even consider changing it?

[chrisjsmith]

@markrendle Other countries here have different moral and privacy standards than America. If you want to do business there you have to meet local regulations.

This isn't good behavior over here.

[markrendle]

@chrisjsmith I think you may have taken my analogy literally. I am saying that a vanishingly-small (0.000001%) minority, however vocal, cannot reasonably expect to effect change in the face of over-whelming indifference. We live in a world where almost everything we do is quantified in some way, mostly (as in this case) a completely benign way used to improve experiences. Every time you watch a show on cable or Netflix, it's counted. Every time you visit a website or click a button, it's counted. Every time you make a call it's counted. Every kilowatt of electricity you consume is measured and recorded and aggregated against millions of other consumers' data to enable better management of the grid. And statistically speaking, nobody cares. If they did, Google and Facebook wouldn't be two of the biggest companies in history.

[kspeakman]

They probably read Nudge, by newly-minted Nobel Laureate Richard H.
Thaler.

Nah, too busy counting money and watching our webcams to be bothered.

On Wed, Oct 11, 2017 at 6:55 AM, Mark Rendle [e-mail]
wrote:

@kspeakman https://github.com/kspeakman

I have a question for you. MS used to have opt-in telemetry for nearly all
products. But in the last years has switched to opt-out for basically
everything. Why?

They probably read Nudge https://en.wikipedia.org/wiki/Nudge_(book), by
newly-minted Nobel Laureate Richard H. Thaler.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/3093#issuecomment-335785516, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEXtDMAu3si_TSiZUtGzbJu2Y1ty9Fkpks5srKytgaJpZM4Ig9GI
.

[markrendle]

@kspeakman See, that's the thing. They're not watching your webcam, and the thing we're discussing is free.

Nobody inside Microsoft is going "oh my hecking gosh, Kasey just ran dotnet new mvc for the fifth time today!". There is absolutely no reason whatsoever for anybody inside Microsoft to brute-force the hashing algorithm used for the machine identifier to identify the IP address of a user, then apply to their ISP to find out exactly who that user is, so they can tell exactly who this idiot is who regularly types dotnet rnu (clue: it's me). It is harmless telemetry gathered purely for the purpose of knowing how, in aggregate, at a scale of millions of users, people are using the software, to identify ways in which it could possibly be improved, or which platforms are the most popular, or how long certain operations take, or whatever. Nobody sits and reads any individual line of data that comes in. It's a massive database with hundreds of millions of data points. The unique hashed machine identifier exists purely for the purposes of

SELECT COUNT(DISTINCT [MachineId])
FROM [Actions]
WHERE [ActionName] = 'publish';

so they can see how many different users do a thing, rather than how often a thing is done. It's no more invasive or violate-y than the little light sensors that count people walking into a supermarkets or up and down the cereal aisle, or the pressure sensors in the road that count how many vehicles drive over them, or the package download counters on NuGet or NPM, or any of the thousands of data points that are collected on you each and every day and aggregated onto charts or into deep learning algorithms to try and understand, and maybe improve, the increasingly complex world in which we live.

[kspeakman]

@markrendle Maybe it is harmless today, but there's no guarantee tomorrow.
Increased telemetry collection has already been announced.

The webcam comment was for the general policy of now everything from
Microsoft (free or not) gathers data and reports it back to them by
default. Some can't even be turned off. Who knows what they actually have
access to in total.

And I love the "everybody else is doing it" argument. :)

On Wed, Oct 11, 2017 at 11:16 AM, Mark Rendle [e-mail]
wrote:

@kspeakman https://github.com/kspeakman See, that's the thing. They're
not watching your webcam, and the thing we're discussing is free.

Nobody inside Microsoft is going "oh my hecking gosh, Kasey just ran dotnet
new mvc for the fifth time today!". There is absolutely no reason
whatsoever for anybody inside Microsoft to brute-force the hashing
algorithm used for the machine identifier to identify the IP address of a
user, then apply to their ISP to find out exactly who that user is, so they
can tell exactly who this idiot is who regularly types dotnet rnu (clue:
it's me). It is harmless telemetry gathered purely for the purpose of
knowing how, in aggregate, at a scale of millions of users, people
are using the software, to identify ways in which it could possibly be
improved, or which platforms are the most popular, or how long certain
operations take, or whatever. Nobody sits and reads any individual line of
data that comes in. It's a massive database with hundreds of millions of
data points. The unique hashed machine identifier exists purely for the
purposes of

SELECT COUNT(DISTINCT [MachineId])FROM [Actions]WHERE [ActionName] = 'publish';

so they can see how many different users do a thing, rather than how often
a thing is done. It's no more invasive or violate-y than the little light
sensors that count people walking into a supermarkets or up and down the
cereal aisle, or the pressure sensors in the road that count how many
vehicles drive over them, or the package download counters on NuGet or NPM,
or any of the thousands of data points that are collected on you each and
every day and aggregated onto charts or into deep learning algorithms to
try and understand, and maybe improve, the increasingly complex world in
which we live.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/3093#issuecomment-335864132, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEXtDF2FY2BuB-DZLE7cZPyjFiywgn2pks5srOnTgaJpZM4Ig9GI
.

[markrendle]

@kspeakman That was not an "everybody else is doing it" argument. It was a ranking of where this kind of telemetry rates in the modern, pervasively-monitored world. You are no more identifiable, identified or interesting than a small hatchback triggering an "intelligent" traffic light. The world runs on data. Of course it is collected. But if you think anything you do ever registers anywhere except as a single unit within an aggregated number expressed in multiples of millions or billions, or with anything other than an algorithm designed to try and sell you and every other human being on this planet things that they don't really want or need, then I would refer you to Tyler Durden.

I, in turn, love the "but what about tomorrow?" argument. If something is harmless today, but becomes harmful tomorrow, then the time to worry about it is tomorrow. And as long as all they collect is telemetry (i.e. aggregated and sliced numbers), and it doesn't actually slow down my internet connection, I really can't imagine any possible harm. Rest assured that if, at any point, it is revealed that Microsoft have been gathering secure credentials for databases and storing them, even reversibly-encrypted, then I will open an issue of my own to complain about it.

[kspeakman]

@markrendle "Everybody else is doing it" was referring to your exchanges
with others, not me. (and also things I've seen from MS employees)

It's fine that you implicitly trust what a company does with your
information until proven otherwise. But I don't. So you'll have to forgive
me for not trusting you to raise an issue on behalf of all of us when it
goes too far. It's already a demonstrated hole that leaks information. I'd
rather it be plugged now and then there's nothing to think about tomorrow.

On Wed, Oct 11, 2017 at 12:28 PM, Mark Rendle [e-mail]
wrote:

@kspeakman https://github.com/kspeakman That was not an "everybody else
is doing it" argument. It was a ranking of where this kind of telemetry
rates in the modern, pervasively-monitored world. You are no more
identifiable, identified or interesting than a small hatchback triggering
an "intelligent" traffic light. The world runs on data. Of course it is
collected. But if you think anything you do ever registers anywhere except
as a single unit within an aggregated number expressed in multiples of
millions or billions, or with anything other than an algorithm designed to
try and sell you and every other human being on this planet things that
they don't really want or need, then I would refer you to Tyler Durden.

I, in turn, love the "but what about tomorrow?" argument. If something is
harmless today, but becomes harmful tomorrow, then the time to worry about
it is tomorrow. And as long as all they collect is telemetry (i.e.
aggregated and sliced numbers), and it doesn't actually slow down my
internet connection, I really can't imagine any possible harm. Rest assured
that if, at any point, it is revealed that Microsoft have been gathering
secure credentials for databases and storing them, even
reversibly-encrypted, then I will open an issue of my own to complain about
it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/3093#issuecomment-335885470, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEXtDAIcTChLUHDR2ridFemaWC9hU6t7ks5srPqqgaJpZM4Ig9GI
.

[svick]

@kspeakman

I'd rather it be plugged now and then there's nothing to think about tomorrow.

If you don't trust Microsoft at all (and you also don't trust the community to keep them in check), then you will always have to think about it, because they could reintroduce telemetry at any moment.

So I don't see how removing the telemetry that you consider harmless improves the situation for you in any way.

[kspeakman]

@markrendle I know you don't see it. And that's why I'm closing my end of
the conversation for now. Good luck!

On Wed, Oct 11, 2017 at 12:45 PM, Petr Onderka [e-mail]
wrote:

@kspeakman https://github.com/kspeakman

I'd rather it be plugged now and then there's nothing to think about
tomorrow.

If you don't trust Microsoft at all (and you also don't trust the
community to keep them in check), then you will always have to think about
it, because they could reintroduce telemetry at any moment.

So I don't see how removing the telemetry that you consider harmless
improves the situation for you in any way.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/3093#issuecomment-335891711, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEXtDEFe6I1DoLyH4NTx2kWEjxoiyjN2ks5srP67gaJpZM4Ig9GI
.

[rustybox]

No one said it needs to be removed, just that the default should be off and one should ask nicely for permission to capture the harmless data.

[markrendle]

@rustybox If the default were off and you had to set an environment variable to turn it on, they would get no data, because nobody cares enough one way or the other to do anything about it at all. "We're going to benignly collect anonymous numbers about how people use this software; you can turn this off if you want" is the default position these days, and software gets better (not to mention more secure) because of it.

[rustybox]

If the installer is run with admin privileges it can set the env var itself.

Would you like to help us make dotnet core better by allowing us to collect some harmless telemetry N/y?
>

[markrendle]

Case in point

[markrendle]

@rustybox Not on Linux.

[dazinator]

@markrendle

If the default were off and you had to set an environment variable to turn it on, they would get no data, because nobody cares enough one way or the other to do anything about it at all.

Well, they would get data from those users that value the product and want to help make it better (like me). I would personally choose to enable telemetry if I was offered a choice. The only reason I now disable it as a matter of course is becuase I don't like the way the participation in telemetry is taken for granted - and I think having to set an environment variable after the install is a deliberate attempt to make it one step removed (and thus easier for the user to forget about opting out later) from the install. I know why its done this way, like you say they _will_ get more data.

[h3smith]

When I setup my iPhone or Macbook - Apple asks me if I want to share diagnostic data with them. On the other hand, Microsoft, you can't disable all of their data tracking in Windows 10. It is virtually impossible.

If it can be done at the OS level, as Apple has shown, it can be done at the level of .NET Core. It is easy to do, the problem of asking is they are too lazy to implement an easy feature.

[sushihangover]

@migueldeicaza Been staying away from this thread, its turned into a religious war.

No 3rd-party extensions installed, latest VS4M, latest Xamarin.XXXX (alpha channel normally), I "assumed" it was a part of the "Visual Studio Experience Improvement Program" that you can not turn it off in non-stable releases. Really noticeable in the firewall reports at one client site since we have to review them with the CSO as our Virtual Machine MAC addresses are tied to the connection (I use Little Snitch to block it on personal Macs) but in secure sites we do not use own own laptops directly for coding, just managed macOS VMs and the firewalls there block all outbound traffic by default):

Deny the following outgoing connections from xx:xx:xx:xx:xx:xx (via mono-sgen64 process on VMccc8f02) to domain mixpanel.com:

Little Snitch reports it as:

/Applications/Visual Studio.app/Contents/MacOS/VisualStudio via /Library/Frameworks/Mono.framework/Versions/5.4.0/bin/mono-sgen64

If it is not coming from Microsoft/Xamarin/MonoDevelop/Mono code, then the only thing I can think of off the top of my head is a Nuget-based "tool" that is executing during a MSBuild run. I'll do a couple tests tonight and a mitmproxy capture if needed so I can so I can read the secure contents of what is being sent to determine the "who".

[inoperable]

Everyone should take a step back and think what this is about - for me its about saying it's NOT ok to yet another step towards complete lack of any privacy, since "it's OK". Yet it might or might not be, the key problem is that companies push it every year slightly further and further, and if everyone won't stand against it - it will be OK at some point that your insurance company, bank, creditor or law firm tells you they can't offer you some service (since some algorithm somewhere put you in the pile of risky clients, but they wont tell you that). It's already happening all around- it might not happen to you in a month or year, but at some point it will. Just think about the amount of digital footsteps we leave each day behind.

Therefore I don't want Microsoft to gather any kind of data about anything WITHOUT MY EXPLICIT CONSENT. It's not OK and let's focus on this please!

I strongly advise anyone who might think "I don't have anything to hide" to read about BigData related ethics and the issues involved. By the end of the day any kind of output is a prediction - but no one cares and takes the same prediction for granted - the same prediction might misleadingly or unjustly categorize YOU in a harmful manner - this is the issue for me. You might think - but how? Simply, by the data every company is gathering about you - since it's OK. Think about it.

If we all just stand by and say "It's ok" then companies will push this further and further.

[mesteche]

if 250 Americans think a law is unjust, should the United States federal government even consider changing it?

What if these 250 Americans are part of a minority which this law allows to oppress, for instance ?
It's not about the number of people who feel concerned, it's about why they do.
And in the current situation, no one is concerned about collecting data (even private data). The issue is about not explicitly asking.
No one decided to use .NET because "it has telemetry", it's not a feature for the user, hence it should require explicit consent to be enabled.

[voronoipotato]

I think the failure for many people in this discussion to understand consent is telling of the state of the industry.

[dazinator]

@markrendle

If the default were off and you had to set an environment variable to turn it on, they would get no data, because nobody cares enough one way or the other to do anything about it at all.

I don't think anyone is asking for this to be as equally cumbersome to enable as it is to disable. We just want the user to be asked for their consent (i.e show a checkbox on the installer, or ask a yes / no question on first use of the cli) - the default selection could still be yes (opt in), but atleast users could opt out there and then if they wish. There should be no need to have to come back later and set an environment variable imho.

[raymondSeger]

User should be asked every-time you want to store their private data.
User should understand what data you are storing.
User should understand that the data is temporarily stored or permanently stored.

~ Stallman

[migueldeicaza]

We are going to allow for this telemetry to be turned off on Alpha releases. But I still do not understand why we have code that logs into mixpanel.

[dandago]

I know it's been a while, but is .NET Core telemetry still opt-in? I wonder whether this constitutes a violation of GDPR now.

[drugarce]

I installed .net core today and the telemetry option was not opt-in. Clearly a violation of GDPR since the data that is shared includes personal information

edit
Wow, what I thought to be an innocent comment got way more attention than it should. Just to clarify, I did not intend to start an anti-Microsoft campaign, I simply wanted to report the issue through what I assumed to be the most appropriate channel.

The .net core documentation page states that (among other stuff) this data is collected

Hashed MAC address: a cryptographically (SHA256) anonymous and unique ID for a machine. This metric is not published.

The FAQ page of the EUGDPR.org website states: (note emphasis mine)

What constitutes personal data?

The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an _identifier_. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or _online identifier_, reflecting changes in technology and the way organisations collect information about people.

The way I interpret this, an _identifier_ based on the MAC address of the PC where the SDK is installed is considered personal data and hence the data collection should follow the guidelines from the GDPR regulations.

[dasMulli]

About GDPR: it would only violate if it collected personal data or data allowing to identify an individual.
AFAIK app insights doesn’t persist IP addresses since February so I guess this should be okay-ish (assuming no other data would be a violation)
edit: there’s also no Session data. Not sure about machine infos
edit 2: apparently hashed MAC address is sent

[mtimofiiv]

I don't use .NET (I came here from Hackernews). But just so you know, this is the kind of thing that gives this software and your brand in general a horrible reputation. I for example use VS Code as my editor of choice and when I first read about this telemetry stuff a while back, I went through the source to check for this anti-feature being built into that too. I will not install Windows on principle because I know it's loaded with your pushy telemetry as well. Apple clearly asks you ONCE if you want to report anonymous usage statistics to them, and it's one checkbox to deal with in the setup of the machine.

It does not take a lot of effort on your part to make the choice opt-in rather than opt-out by default, and no argumentation that project contributors or anyone else made in this thread or others of this type (there are a couple issues on here if I remember correctly about the topic of telemetry) have clearly been able to show why doing so would somehow compromise your product feedback.

So listen to your users who are clearly speaking out against this telemetry (or rather the way you choose to context the collection of it). All you have to do is make it compliant to their expectations, because that's what building great user experiences is all about. I don't get why this is so hard to understand.

These telemetry GH issues demonstrate that people are passionate about your product and about their own privacy. Do the decent thing and stop jamming your telemetry down people's throats.

[Zenexer]

Opt-out is still unacceptable. None of the (potential) users complaining about this are going to be satisfied unless it’s opt-in. I love .NET, and even I’m hesitant to use Core if I have to do a dance to avoid telemetry, as it presents an obvious legal and PR risk for me.

[ibakirov]

I agree, should be option to opt out this feature

[roebuk]

It's not just dotnet/cli that's guilty of this, Office-js is also collecting user data without explicit consent. https://github.com/OfficeDev/office-js/issues/61

[kiicia]

@dasMulli practically any datum is considered personal data, it does not need to be ip address, even user-agent is identifying (especially with other data) - this is exact strategy that spammers use to have persistent fingerprint of you
and that's why it is opt-in - because someone must check what data is collected and what is it used for, then write it all and ask user for permission
it is exactly opposite to current strategy to collect as much data as possible for current and future use

[tadas-subonis]

@kiicia No. You have to be able to identify an individual person by the given data. Identifying and telling "it's the same customer" is not the same. Using IP, you can identify a person by asking ISP to whom does that IP belong. You can't do that with User Agent or a cookie.

[creshal]

You're still violating the "privacy by default" principle of the GDPR, as some of these data could be PII under some circumstances (exotic UA combinations e.g.). Opt in would solve a lot of potential legal headaches.

[chrisjsmith]

Something to back this complaint up:

User's hashed MAC address is sent by default. This is consistently hashed so can be correlated across other information sources to identify a user.

https://github.com/dotnet/cli/blob/b45f1fb439b36872c249b07f1c6bddf20167f166/src/dotnet/Telemetry/Sha256Hasher.cs#L12

This is seriously not on.

[kiicia]

@tadas-subonis it depends on who you ask, there are internal corporate trainings/policies which clearly state what is considered personal data and what is not (consulted with/interpreted by lawyers) and it seems that any literal datum "produced" by client is automatically user data no matter how trivial it may seem
also some companies downplay/ignore certain details because it is their modus operandi to gather and use all available data
there is however clause about "data which are necessary to use/work with/deliver service" - for example you may require certain data because you are unable to deliver service otherwise... then consent can be implicit by sole decision to use service - it is also used to explain why certain amount of data must be gathered, still you need to say something to user/client and give them chance to express their decision

[bhartvigsen]

I have to admire Microsoft's consistent use of the word "telemetry" across all its various privacy-violating platforms and practices.

[WenJianhub]

微软现在可以说是操作系统一家独大，所以说有时候可能会忽略掉一些用户在意的问题。对于.Net Core 收集用户信息这个问题我的想法是 —— 这个问题不应该再有过多的争议，显然用户是对微软的收集方式不满。那么微软最直接、最合理的做法不应该就是在统计用户信息之前给用户一个右好的提示和选择；并将收集范围告知用户，给予用户完全的选择权吗？最后的结果也很简单：1.微软采纳用户合理意见 2.微软不采纳用户意见，首先微软需要对用户提议有一个明确的态度！

[dandago]

Microsoft doesn't give a toss what the community wants. Open source for them is just a way to get code improvements and documentation into their systems at other people's expense.

[Meyhem]

Why has the opt-out has to be so hard ? Setting one long env. variable on every process ? It seems microsoft is making quite an effort to provide UX that obscures anything it doesn't want you to see.
Wouldn't it be nicer to get prompt during install, not just info message about crime already comitted ?
Or at least telemetry-less packages ?

[svick]

@Meyhem

Setting one long env. variable on every process ?

Every OS I know lets you set the environment variable once in a way that applies to every process.

[chrisjsmith]

This isn't a technical discussion. We can set environment variables.

We are asking for opt-in with explicit consent, not opt-out.

This is a sign of respect for your userbase, something which we demand after years of abuse.

[chrisjsmith]

There's a fine example of where opt out telemetry goes to crap...

[dasMulli]

@kstarikov I think you could/should create a new issue for this

[dgl]

I sent a security report to Microsoft detailing how the collected data is not anonymous, but they didn't consider it a security issue. The write-up is now publicly available here: https://dgl.cx/2020/08/ms-report.txt

Given the fact it is easy to accidentally send data to Microsoft I have written up how to send a right to object request here: https://dgl.cx/2020/08/dotnet-sdk-gdpr