New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET core should not SPY on users by default #3093

Closed
ghost opened this Issue May 18, 2016 · 206 comments

Comments

Projects
None yet
@ghost

ghost commented May 18, 2016

@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 #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

This comment has been minimized.

Show comment
Hide comment
@richlander

richlander May 18, 2016

Member

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.

Member

richlander commented May 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 18, 2016

Contributor

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

Contributor

guardrex commented May 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst May 18, 2016

Member

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.

Member

terrajobst commented May 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst May 18, 2016

Member

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.

Member

terrajobst commented May 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 18, 2016

Contributor

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

Contributor

guardrex commented May 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@richlander

richlander May 18, 2016

Member

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

Member

richlander commented May 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 19, 2016

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.

ghost commented May 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones May 19, 2016

Contributor

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:

screen shot 2016-05-19 at 10 26 05 am

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

Contributor

vcsjones commented May 19, 2016

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:

screen shot 2016-05-19 at 10 26 05 am

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

@TheRealPiotrP TheRealPiotrP added this to the 1.0.0-rtm milestone May 26, 2016

@mmc41

This comment has been minimized.

Show comment
Hide comment
@mmc41

mmc41 Jun 10, 2016

@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!

mmc41 commented Jun 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones Jun 10, 2016

Contributor

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

Contributor

vcsjones commented Jun 10, 2016

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

@h3smith

This comment has been minimized.

Show comment
Hide comment
@h3smith

h3smith Jun 28, 2016

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

h3smith commented Jun 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Jun 28, 2016

Member

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

Member

akoeplinger commented Jun 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex Jun 28, 2016

Contributor

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.

Contributor

guardrex commented Jun 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dlebedynskyi

dlebedynskyi Jun 28, 2016

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.

dlebedynskyi commented Jun 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kspeakman

kspeakman Jul 1, 2016

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

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

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex Jul 1, 2016

Contributor

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

Contributor

guardrex commented Jul 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@RomanShumikhin

RomanShumikhin Jul 3, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@mschlechter

mschlechter Jul 10, 2016

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.

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 comment has been minimized.

Show comment
Hide comment
@rustybox

rustybox Jul 14, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@linkdata

linkdata Sep 19, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@hardhub

hardhub Sep 23, 2016

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.

hardhub commented Sep 23, 2016

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.

@johnwilkey

This comment has been minimized.

Show comment
Hide comment
@johnwilkey

johnwilkey Nov 26, 2016

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.

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.

@blackdwarf blackdwarf modified the milestones: Discussion, 1.0.0-rtm Jan 19, 2017

@CodesInChaos

This comment has been minimized.

Show comment
Hide comment
@CodesInChaos

CodesInChaos Mar 16, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@hardhub

hardhub Mar 16, 2017

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

hardhub commented Mar 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones Mar 16, 2017

Contributor

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

Contributor

vcsjones commented Mar 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@hardhub

hardhub Mar 19, 2017

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

hardhub commented Mar 19, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@OpinionatedGeek

OpinionatedGeek Mar 20, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones Mar 20, 2017

Contributor

@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

Contributor

vcsjones commented Mar 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@OpinionatedGeek

OpinionatedGeek Mar 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones Mar 20, 2017

Contributor

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.

Contributor

vcsjones commented Mar 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@OpinionatedGeek

OpinionatedGeek Mar 21, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@slawo

slawo Apr 18, 2017

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

slawo commented Apr 18, 2017

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

@kspeakman

This comment has been minimized.

Show comment
Hide comment
@kspeakman

kspeakman Oct 11, 2017

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle Oct 11, 2017

Contributor

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

Contributor

markrendle commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kspeakman

kspeakman Oct 11, 2017

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle Oct 11, 2017

Contributor

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

Contributor

markrendle commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kspeakman

kspeakman Oct 11, 2017

@svick

This comment has been minimized.

Show comment
Hide comment
@svick

svick Oct 11, 2017

Contributor

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

Contributor

svick commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kspeakman

kspeakman Oct 11, 2017

@rustybox

This comment has been minimized.

Show comment
Hide comment
@rustybox

rustybox Oct 11, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle Oct 11, 2017

Contributor

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

Contributor

markrendle commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rustybox

rustybox Oct 11, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
Contributor

markrendle commented Oct 11, 2017

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle Oct 11, 2017

Contributor

@rustybox Not on Linux.

Contributor

markrendle commented Oct 11, 2017

@rustybox Not on Linux.

@dazinator

This comment has been minimized.

Show comment
Hide comment
@dazinator

dazinator Oct 11, 2017

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

dazinator commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@h3smith

h3smith Oct 11, 2017

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.

h3smith commented Oct 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sushihangover

sushihangover Oct 11, 2017

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

sushihangover commented Oct 11, 2017

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

@jankun

This comment has been minimized.

Show comment
Hide comment
@jankun

jankun Oct 14, 2017

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.

jankun commented Oct 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mesteche

mesteche Oct 15, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@voronoipotato

voronoipotato Oct 16, 2017

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

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

@dazinator

This comment has been minimized.

Show comment
Hide comment
@dazinator

dazinator Oct 16, 2017

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

dazinator commented Oct 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@raymondSeger

raymondSeger Oct 18, 2017

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

raymondSeger commented Oct 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@migueldeicaza

migueldeicaza Nov 5, 2017

Member

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.

Member

migueldeicaza commented Nov 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dandago

dandago May 26, 2018

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.

dandago commented May 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@drugarce

drugarce May 29, 2018

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.

drugarce commented May 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli May 29, 2018

Contributor

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

Contributor

dasMulli commented May 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mtimofiiv

mtimofiiv May 29, 2018

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.

mtimofiiv commented May 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Zenexer

Zenexer May 29, 2018

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.

Zenexer commented May 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ibakirov

ibakirov May 29, 2018

I agree, should be option to opt out this feature

I agree, should be option to opt out this feature

@roebuk

This comment has been minimized.

Show comment
Hide comment
@roebuk

roebuk May 29, 2018

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

roebuk commented May 29, 2018

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

@kiicia

This comment has been minimized.

Show comment
Hide comment
@kiicia

kiicia May 29, 2018

@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

kiicia commented May 29, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@tadas-subonis

tadas-subonis May 29, 2018

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

@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

This comment has been minimized.

Show comment
Hide comment
@creshal

creshal May 29, 2018

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.

creshal commented May 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@chrisjsmith

chrisjsmith May 29, 2018

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.

/// // The hashed mac address needs to be the same hashed value as produced by the other distinct sources given the same input. (e.g. VsCode)

This is seriously not on.

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.

/// // The hashed mac address needs to be the same hashed value as produced by the other distinct sources given the same input. (e.g. VsCode)

This is seriously not on.

@kiicia

This comment has been minimized.

Show comment
Hide comment
@kiicia

kiicia May 29, 2018

@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

kiicia commented May 29, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@bhartvigsen

bhartvigsen May 30, 2018

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

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

@WenJianhub

This comment has been minimized.

Show comment
Hide comment
@WenJianhub

WenJianhub Jun 15, 2018

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

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

@tim241

This comment has been minimized.

Show comment
Hide comment
@tim241

tim241 Jul 24, 2018

so doesn't Microsoft see that the community wants this to be opt-in?
Maybe Microsoft should rethink their strategy on opensource, without the community efforts, this project wouldn't be this great so it'd be better to listen to your community.

tim241 commented Jul 24, 2018

so doesn't Microsoft see that the community wants this to be opt-in?
Maybe Microsoft should rethink their strategy on opensource, without the community efforts, this project wouldn't be this great so it'd be better to listen to your community.

@dandago

This comment has been minimized.

Show comment
Hide comment
@dandago

dandago Jul 24, 2018

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.

dandago commented Jul 24, 2018

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.

@gnarpaws

This comment has been minimized.

Show comment
Hide comment
@gnarpaws

gnarpaws Aug 11, 2018

Why is micro$haft still in business? ((They)) should be fined into oblivion for things like this. ("[ISSUE CLOSED]")

Why is micro$haft still in business? ((They)) should be fined into oblivion for things like this. ("[ISSUE CLOSED]")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment