5 ms·

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

142 points by mel919 9y ago

0xFFC 9y ago
tl;dr please?
- mel919 9y ago
  Microsoft introduced telemetry enabled by default to .NET Core CLI.
- dvfjsdhgfv 9y ago
  The OP is not happy with the fact collects the telemetry data when you use their .NET tools and demands that they stop. (I'm almost sure this post will be featured on n-gate.com.)
  - deleted 9y ago
    [deleted]
orf 9y ago
For reference, they collect[1]: The command being used (for example, "build", "restore") The ExitCode of the command For test projects, the test runner being used The timestamp of invocation The framework used Whether runtime IDs are present in the "runtimes" node The CLI version being used I'm actually OK with this to be honest. Here is the telemetry code itself: https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f958300aa20329e5ccaa7/src/dotnet/Telemetry.cs#L92-L104 https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f95830... They also publish all the telemetry data (Change 2016 and q3): https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-usage-2016-q3.tsv https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli... 1. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry
- Avalaxy 9y ago
  So this is yet another case of someome blowing something completely out of proportions and spending their time working on something completely useless that will never benefit them.
  - princekolt 9y ago
    "Out of proportions" for now. Nothing stops them from changing this later, updating the small print saying "oh we changed that" and blaming you for not checking for changes to their EULA regularly.
    - Klathmon 9y ago
      If this is your fear how do you use any software? MS could update your OS to do anything tomorrow, Canonical could hide some literal malware in any number of packages for Ubuntu tonight, Intel could write a backdoor into your machine in it's next microcode update. And OSS doesn't fully prevent this either. GCC could add some kind of nefarious exploit in the next version of it's compiler (knowingly or otherwise). Just take a look at the underhanded c competition for just how scary easy it is to hide exploits in plain sight! I can't even fathom the amount of work it would be to personally review every line of code that goes into your machine from the microcode up to the newest NPM module (even if it were all open and it was possible to do). At some point you need to trust someone else.
      - pdkl95 9y ago
        That's why betrayals of trust - such as adding spyware that takes data without the user's informed consent ("opt-out") - are such a big problem. You're right - there isn't enough time to audit everything, so we have to rely on trust. "Relying on trust" means instead of reviewing code, you have to review trustworthiness.
- merb 9y ago
  do you actually inspect every github commit, that this won't change?
wereHamster 9y ago
On mac you can always use little snitch (https://www.obdev.at/products/littlesnitch/index.html https://www.obdev.at/products/littlesnitch/index.html) to reliably block outgoing connections. No need to muck around with environment variables, and you don't have to guess which domains dotnet uses, little snitch will tell you, even if they change them in the future.
- simooooo 9y ago
  I'll just set the environment variable thanks.
  - wereHamster 9y ago
    Haha, who makes sure that dotnet actually honors the env variable? It could still connect to servers and exfiltrate data. OTOH nobody gets around a firewall which blocks all outgoing connections ;)
apk-d 9y ago
This probably feels more unusual in the world of shell-based development tools - not many these days blink an eye for this sort of behaviour from an IDE package. Still, as a .NET core fan, definitely not a fan of this practice. To be expected from Microsoft, though - they bet big on telemetry in their tools and encourage developers to do the same (through tools like App Insights, for example).
- mattmanser 9y ago
  My impression is that no-one uses Application Insights. Total of 643 questions about Application Insights on SO, either it's the easiest tool to use ever, or no-one uses it.
staticelf 9y ago
Come on folks, this is printed out on the use of the command and basically any site today does more intrusive telemetry. I think they should ask people like Yeoman, but I don't think they deserve this much shit for such a small thing.
- shakna 9y ago
  > and basically any site today does more intrusive telemetry So the next version of Bash should have telemetry?
  - staticelf 9y ago
    No but it's big differences in the projects. If Powershell would have gotten telemetry I would understand the objections.
    - shakna 9y ago
      There is an earthshattering difference between a website, a place I go to let someone else run code, and a build tool I use to run code I write.
      - staticelf 9y ago
        What? You run the code in the browser when it comes to javascript just as you run the .NET SDK. The difference is that the .NET SDK tell you that they send telemetry, how to disable it and what they store are not really any sensitive information. Most websites run code with the sole purpose of identifying you.
        shakna 9y ago
        JS engines are supposed to be sandboxed, and have limited APIs to draw from. Unless you use a jail, a local application can do just about anything. The difference is expectation. I expect websites to run things I don't control. I expect a local application to behave in a certain way.
taspeotis 9y ago
Here's what Microsoft have learnt from the telemetry [1]. [1] https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve-learned-from-net-core-sdk-telemetry/ https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...
- shakna 9y ago
  The data is also public, at: https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-usage-<YEAR>-q<QUARTER>.tsv https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli... So, the latest would be: https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-usage-2017-q2.tsv https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...
  - 0x0 9y ago
    I think it's noteworthy that they even include command line arguments that are mistyped, for example "bulid". What happens if you accidentally paste an AWS secret key or similar in the middle of a command line argument? Will that too appear in public csv files a year later?
    - lightbyte 9y ago
      They don't include command line arguments (yet). They include the command verb (dotnet [build/restore/etc]) that was ran.
      - 0x0 9y ago
        Well, it looks like they are including "command verbs" even if they are mistyped, for example "bulid". What happens if you accidentally paste an AWS secret key or similar in the middle of a command verb? Will that too appear in public csv files a year later?
        runfaster2000 9y ago
        See my comment to the grandparent comment on our approach to only including common command strings (which wouldn't include anyone's AWS key). Also, and more importantly, we will only collect known arguments. From the blog post: > Only known arguments and options will be collected (not arbitrary strings). We don't want your AWS secret key in this data as much as you do. We have put systematic mitigations in place to ensure that this doesn't happen.
nmeofthestate 9y ago
Ah, these geeks that hallucinate themselves as Will Smith in Enemy of the State. Never gets old. I think in this case the onus is on the paranoid coder with an inflated sense of their own importance to stop MS getting their hands on the super sekret dotnet usage information. And that's easy - it's a setting. (Non) problem solved.
- uw_rob 9y ago
  > And that's easy - it's a setting. (Non) problem solved. I still don't think this is a non problem. When you are using many different tools that are updating constantly, it is easy to not notice one adding telemetry. And even if you disable it, it very well may be silently reenabled in the future.
  - nmeofthestate 9y ago
    My opinion is coloured by the fact that I think the telemetry gathering is harmless and in fact useful, so not worth getting worked up about. In fact if you use a product why would you want to conserve your 'precious body fluids' (telemetry) instead of helping improve the product? Beats me.
forgottenacc57 9y ago
People remain the same people and companies remain the same companies. It's in microsofts DNA to build stuff that captures and watches and monitors and logs. Just because they've started to be more open, won't change the fundamental company attitude and approach to doing things. Microsoft will simply be bringing more "Microsoftiness" to the open source world. Get used to it, there's more coming cause that's the way they build software. I would suggest that it is time to rethink some of those outdated assumptions that tools won't spy on you. Microsoft have arrived at the open source party, so open source isn't the same any more, just accept that the world has changed and now it's entirely possible that your open source is logging and watching.
yread 9y ago
Should have [2016] added to the title https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/#net-core-tools-telemetry https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin... /s
romanovcode 9y ago
If you are so against telemetry and google analytics specifically maybe you should remove it from your own site?[0] [0] https://imgur.com/a/NX2Gc https://imgur.com/a/NX2Gc
- mel919 9y ago
  I'm not the author of the blog post. I think you're comparing apples and oranges, also this kind of reasoning is an example of "tu quoque" logical fallacy.
  - deleted 9y ago
    [deleted]
  - strictnein 9y ago
    > tu quoque No, this is not that. The "tu quoque" logical fallacy follows this pattern (from Wikipedia): Person A makes claim X. Person B asserts that A's actions or past claims are inconsistent with the truth of claim X. Therefore X is false.[2] They are not saying their claim is false. They're saying that if they care so much, why are they subjecting their users to tracking that they are unable to opt out of?
    - jdmichal 9y ago
      I've struggled with this before on this site. People love to pull out fallacies. But they forget that fallacies are only fallacies if they are used as a counterargument. And even when they are used in such a way, the other side then has to deal with fallacy fallacy. You can't immediately discredit an argument just because it contains a fallacy.
    - mel919 9y ago
      It wasn't stated explicitly. The assumption that I made was it related to the discussion about validity of the topic. Assumptions can be misleading but human language operates in a context. Formally, should the context be taken out, to operate only on the words of the post - you're right - it is not "tu quoque".
RubyPinch 9y ago
"You should be able to run a command that doesn’t use the network, knowing that it won’t open a network port." Is the reader supposed to stop reading there? Because they must be using a different dotnet than everyone else, considering microsoft's dotnet does package management and download iirc? "I don’t want your tools spying on you either." how virtuous. Some people don't care though, some people actually prefer it
- Silhouette 9y ago
  "I don’t want your tools spying on you either." how virtuous. Some people don't care though, some people actually prefer it Then it won't be a problem to disclose exactly what is proposed, get those people's informed consent, and leave everyone else alone, will it?
_pmf_ 9y ago
"Telemetry" ... nice spin.
marenkay 9y ago
What's with this exaggerated blog post? 1. It was announced in the open in June 2016 that .NET Core includes telemetry: https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-net-core-1-0/ https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcin... 2. If you use something you could at least follow changes between major releases, no? When did engineer stop being responsible people and read before using things? :-O
cjsuk 9y ago
Coming from Europe, I'm a little worried by the general attitude here. We tend to side with privacy first. There are some real genuine concerns from real people like myself who have to work with this tooling. I'll detail my thoughts: 1. It's setting a bad precedence for data collection by default. Name one other tool of the same class that actually sends telemetry data home by default? 2. It's much harder to ensure that the tooling is compliant with data protection policies within an organisation if the tooling by default sends telemetry. We now have to assume it's going to send stuff by default and configure all build infrastructure, every developer workstation and every piece of the toolchain independently. This is particularly of concern in the finance sector. It also costs us time and money. 3. There's no test cases to cover the telemetry functionality at all. Check the code. What happens if it starts reporting command lines due to a trivial defect. 4. There is a crudely defined document which describes what the telemetry does, but not what it will do in the future. What happens is a PR appears, gets merged and gets pushed out to a new version. To find out what happens you have to read every merge, every PR for a release. This is a loaded gun waiting for any security conscious team to shoot themselves in the face with. Really this will gate the product into the bin at the first technical review stage for a lot of companies. There is no appetite for being milked. I'd also like to add the absolute zero communications on this front from MSFT. People have asked directly via PRs to turn this off because they do not want it and they have been ignored for over a year. The usual response from MSFT is never to respond directly to this question and instead outline what the telemetry does expecting the question to remain answered. If there's anything I've learned over the years; you can't trust anyone who won't answer a direct question.
Sir_Cmpwn 9y ago
Though this data is more or less benine, the point remains. I don't think it's appropriate for a tool like this to phone home, and if it did, it should at least be opt-in, not opt-out (especially considering the opt-out mechanism is something as clumsy as setting an environment variable rather than a config somewhere). This tool compiles code. Why does it need to make a network call at all? That's going to slow down your builds for the sake of phoning home to Microsoft, a company we don't exactly trust for being good stewards of our information.
raprp 9y ago
This has been discussed for over an year on this issue: https://github.com/dotnet/cli/issues/3093 https://github.com/dotnet/cli/issues/3093 They are just ignoring to let the issue die silently.
amelius 9y ago
I'm not sure what their goal is with this data. Do they want to use this data to create a good tool? Or do they want to use the data to create a tool that appeals to the average user?
ldev1 9y ago
I just wish they would officially support this kind of spying on FreeBSD
zabil 9y ago
We are struggling, philosophically, with anti telemetry posts (like this one). We are turning on telemetry in the next release for our open source tool. https://github.com/getgauge/gauge https://github.com/getgauge/gauge We are small team with limited resources. In our tool, it's easy to turn telemetry off, inspect what data is sent and the data collected is public. The data "really" helps to make the tool better and an opt-in skews the data. We've published an blog post https://blog.getgauge.io/why-we-collect-data-b19df366b677 https://blog.getgauge.io/why-we-collect-data-b19df366b677 and will put it up in the release notes and the download section. What else can be done so that users don't blow up?
- blub 9y ago
  The minimum should be a clearly presented option to turn off telemetry either during install or at first startup.
- mel919 9y ago
  Just a mere suggestion: you may look into how it's done in yeoman (https://github.com/dotnet/cli/issues/3093#issuecomment-220341285 https://github.com/dotnet/cli/issues/3093#issuecomment-22034...) and read this https://github.com/dotnet/cli/issues/3093 https://github.com/dotnet/cli/issues/3093 as there's lots of user input there.
- cjsuk 9y ago
  Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect. If you get an uptake of say 5-10%, if that's worth it then problem solved. If it's not then don't bother adding telemetry to start with. But before you do this, you have to ask the question: how did the software industry get by before the sudden rise of telemetry? It engaged the customer. I think a lot of cases it is used it is used as a substitute for engaging the customer.
  - 9y ago
Piccollo 9y ago
"telemetry", what a euphemism.
shanselman 9y ago
It's somewhat ironic that he feels so strongly about privacy but when I hit his site I get this message: "This website uses cookies to ensure you get the best experience on our website - More info" that links to Google's policy. Regardless, as folks point out, you're notified https://news.ycombinator.com/item?id=14837097 https://news.ycombinator.com/item?id=14837097 so it's not clear when he missed this.
yuhong 9y ago
My favorite actually is https://github.com/dotnet/cli/pull/3494 https://github.com/dotnet/cli/pull/3494 . Of course sending things like IP addresses is unavoidable. I should also mention https://twitter.com/NerdPyle/status/863456558172168192 https://twitter.com/NerdPyle/status/863456558172168192

142 points by mel919 9y ago

0xFFC 9y ago

tl;dr please?

mel919 9y ago
Microsoft introduced telemetry enabled by default to .NET Core CLI.
dvfjsdhgfv 9y ago
The OP is not happy with the fact collects the telemetry data when you use their .NET tools and demands that they stop. (I'm almost sure this post will be featured on n-gate.com.)
- deleted 9y ago
  [deleted]

orf 9y ago

For reference, they collect[1]: The command being used (for example, "build", "restore") The ExitCode of the command For test projects, the test runner being used The timestamp of invocation The framework used Whether runtime IDs are present in the "runtimes" node The CLI version being used I'm actually OK with this to be honest. Here is the telemetry code itself: https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f958300aa20329e5ccaa7/src/dotnet/Telemetry.cs#L92-L104 https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f95830... They also publish all the telemetry data (Change 2016 and q3): https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-usage-2016-q3.tsv https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli... 1. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

Avalaxy 9y ago
So this is yet another case of someome blowing something completely out of proportions and spending their time working on something completely useless that will never benefit them.
- princekolt 9y ago
  "Out of proportions" for now. Nothing stops them from changing this later, updating the small print saying "oh we changed that" and blaming you for not checking for changes to their EULA regularly.
  - Klathmon 9y ago
    If this is your fear how do you use any software? MS could update your OS to do anything tomorrow, Canonical could hide some literal malware in any number of packages for Ubuntu tonight, Intel could write a backdoor into your machine in it's next microcode update. And OSS doesn't fully prevent this either. GCC could add some kind of nefarious exploit in the next version of it's compiler (knowingly or otherwise). Just take a look at the underhanded c competition for just how scary easy it is to hide exploits in plain sight! I can't even fathom the amount of work it would be to personally review every line of code that goes into your machine from the microcode up to the newest NPM module (even if it were all open and it was possible to do). At some point you need to trust someone else.
    - pdkl95 9y ago
      That's why betrayals of trust - such as adding spyware that takes data without the user's informed consent ("opt-out") - are such a big problem. You're right - there isn't enough time to audit everything, so we have to rely on trust. "Relying on trust" means instead of reviewing code, you have to review trustworthiness.
merb 9y ago
do you actually inspect every github commit, that this won't change?

wereHamster 9y ago

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

simooooo 9y ago
I'll just set the environment variable thanks.
- wereHamster 9y ago
  Haha, who makes sure that dotnet actually honors the env variable? It could still connect to servers and exfiltrate data. OTOH nobody gets around a firewall which blocks all outgoing connections ;)

apk-d 9y ago

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

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

staticelf 9y ago

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

shakna 9y ago
> and basically any site today does more intrusive telemetry So the next version of Bash should have telemetry?
- staticelf 9y ago
  No but it's big differences in the projects. If Powershell would have gotten telemetry I would understand the objections.
  - shakna 9y ago
    There is an earthshattering difference between a website, a place I go to let someone else run code, and a build tool I use to run code I write.
    - staticelf 9y ago
      What? You run the code in the browser when it comes to javascript just as you run the .NET SDK. The difference is that the .NET SDK tell you that they send telemetry, how to disable it and what they store are not really any sensitive information. Most websites run code with the sole purpose of identifying you.
      - shakna 9y ago
        JS engines are supposed to be sandboxed, and have limited APIs to draw from. Unless you use a jail, a local application can do just about anything. The difference is expectation. I expect websites to run things I don't control. I expect a local application to behave in a certain way.

taspeotis 9y ago

Here's what Microsoft have learnt from the telemetry [1]. [1] https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve-learned-from-net-core-sdk-telemetry/ https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...

shakna 9y ago
The data is also public, at: https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-usage-<YEAR>-q<QUARTER>.tsv https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli... So, the latest would be: https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-usage-2017-q2.tsv https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...
- 0x0 9y ago
  I think it's noteworthy that they even include command line arguments that are mistyped, for example "bulid". What happens if you accidentally paste an AWS secret key or similar in the middle of a command line argument? Will that too appear in public csv files a year later?
  - lightbyte 9y ago
    They don't include command line arguments (yet). They include the command verb (dotnet [build/restore/etc]) that was ran.
    - 0x0 9y ago
      Well, it looks like they are including "command verbs" even if they are mistyped, for example "bulid". What happens if you accidentally paste an AWS secret key or similar in the middle of a command verb? Will that too appear in public csv files a year later?
      - runfaster2000 9y ago
        See my comment to the grandparent comment on our approach to only including common command strings (which wouldn't include anyone's AWS key). Also, and more importantly, we will only collect known arguments. From the blog post: > Only known arguments and options will be collected (not arbitrary strings). We don't want your AWS secret key in this data as much as you do. We have put systematic mitigations in place to ensure that this doesn't happen.

nmeofthestate 9y ago

Ah, these geeks that hallucinate themselves as Will Smith in Enemy of the State. Never gets old. I think in this case the onus is on the paranoid coder with an inflated sense of their own importance to stop MS getting their hands on the super sekret dotnet usage information. And that's easy - it's a setting. (Non) problem solved.

uw_rob 9y ago
> And that's easy - it's a setting. (Non) problem solved. I still don't think this is a non problem. When you are using many different tools that are updating constantly, it is easy to not notice one adding telemetry. And even if you disable it, it very well may be silently reenabled in the future.
- nmeofthestate 9y ago
  My opinion is coloured by the fact that I think the telemetry gathering is harmless and in fact useful, so not worth getting worked up about. In fact if you use a product why would you want to conserve your 'precious body fluids' (telemetry) instead of helping improve the product? Beats me.

forgottenacc57 9y ago

People remain the same people and companies remain the same companies. It's in microsofts DNA to build stuff that captures and watches and monitors and logs. Just because they've started to be more open, won't change the fundamental company attitude and approach to doing things. Microsoft will simply be bringing more "Microsoftiness" to the open source world. Get used to it, there's more coming cause that's the way they build software. I would suggest that it is time to rethink some of those outdated assumptions that tools won't spy on you. Microsoft have arrived at the open source party, so open source isn't the same any more, just accept that the world has changed and now it's entirely possible that your open source is logging and watching.

yread 9y ago

Should have [2016] added to the title https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/#net-core-tools-telemetry https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin... /s

romanovcode 9y ago

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

mel919 9y ago
I'm not the author of the blog post. I think you're comparing apples and oranges, also this kind of reasoning is an example of "tu quoque" logical fallacy.
- deleted 9y ago
  [deleted]
- strictnein 9y ago
  > tu quoque No, this is not that. The "tu quoque" logical fallacy follows this pattern (from Wikipedia): Person A makes claim X. Person B asserts that A's actions or past claims are inconsistent with the truth of claim X. Therefore X is false.[2] They are not saying their claim is false. They're saying that if they care so much, why are they subjecting their users to tracking that they are unable to opt out of?
  - jdmichal 9y ago
    I've struggled with this before on this site. People love to pull out fallacies. But they forget that fallacies are only fallacies if they are used as a counterargument. And even when they are used in such a way, the other side then has to deal with fallacy fallacy. You can't immediately discredit an argument just because it contains a fallacy.
  - mel919 9y ago
    It wasn't stated explicitly. The assumption that I made was it related to the discussion about validity of the topic. Assumptions can be misleading but human language operates in a context. Formally, should the context be taken out, to operate only on the words of the post - you're right - it is not "tu quoque".

RubyPinch 9y ago

"You should be able to run a command that doesn’t use the network, knowing that it won’t open a network port." Is the reader supposed to stop reading there? Because they must be using a different dotnet than everyone else, considering microsoft's dotnet does package management and download iirc? "I don’t want your tools spying on you either." how virtuous. Some people don't care though, some people actually prefer it

Silhouette 9y ago
"I don’t want your tools spying on you either." how virtuous. Some people don't care though, some people actually prefer it Then it won't be a problem to disclose exactly what is proposed, get those people's informed consent, and leave everyone else alone, will it?

_pmf_ 9y ago

"Telemetry" ... nice spin.

marenkay 9y ago

What's with this exaggerated blog post? 1. It was announced in the open in June 2016 that .NET Core includes telemetry: https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-net-core-1-0/ https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcin... 2. If you use something you could at least follow changes between major releases, no? When did engineer stop being responsible people and read before using things? :-O

cjsuk 9y ago

Coming from Europe, I'm a little worried by the general attitude here. We tend to side with privacy first. There are some real genuine concerns from real people like myself who have to work with this tooling. I'll detail my thoughts: 1. It's setting a bad precedence for data collection by default. Name one other tool of the same class that actually sends telemetry data home by default? 2. It's much harder to ensure that the tooling is compliant with data protection policies within an organisation if the tooling by default sends telemetry. We now have to assume it's going to send stuff by default and configure all build infrastructure, every developer workstation and every piece of the toolchain independently. This is particularly of concern in the finance sector. It also costs us time and money. 3. There's no test cases to cover the telemetry functionality at all. Check the code. What happens if it starts reporting command lines due to a trivial defect. 4. There is a crudely defined document which describes what the telemetry does, but not what it will do in the future. What happens is a PR appears, gets merged and gets pushed out to a new version. To find out what happens you have to read every merge, every PR for a release. This is a loaded gun waiting for any security conscious team to shoot themselves in the face with. Really this will gate the product into the bin at the first technical review stage for a lot of companies. There is no appetite for being milked. I'd also like to add the absolute zero communications on this front from MSFT. People have asked directly via PRs to turn this off because they do not want it and they have been ignored for over a year. The usual response from MSFT is never to respond directly to this question and instead outline what the telemetry does expecting the question to remain answered. If there's anything I've learned over the years; you can't trust anyone who won't answer a direct question.

Sir_Cmpwn 9y ago

Though this data is more or less benine, the point remains. I don't think it's appropriate for a tool like this to phone home, and if it did, it should at least be opt-in, not opt-out (especially considering the opt-out mechanism is something as clumsy as setting an environment variable rather than a config somewhere). This tool compiles code. Why does it need to make a network call at all? That's going to slow down your builds for the sake of phoning home to Microsoft, a company we don't exactly trust for being good stewards of our information.

raprp 9y ago

This has been discussed for over an year on this issue: https://github.com/dotnet/cli/issues/3093 https://github.com/dotnet/cli/issues/3093 They are just ignoring to let the issue die silently.

amelius 9y ago

I'm not sure what their goal is with this data. Do they want to use this data to create a good tool? Or do they want to use the data to create a tool that appeals to the average user?

ldev1 9y ago

I just wish they would officially support this kind of spying on FreeBSD

zabil 9y ago

We are struggling, philosophically, with anti telemetry posts (like this one). We are turning on telemetry in the next release for our open source tool. https://github.com/getgauge/gauge https://github.com/getgauge/gauge We are small team with limited resources. In our tool, it's easy to turn telemetry off, inspect what data is sent and the data collected is public. The data "really" helps to make the tool better and an opt-in skews the data. We've published an blog post https://blog.getgauge.io/why-we-collect-data-b19df366b677 https://blog.getgauge.io/why-we-collect-data-b19df366b677 and will put it up in the release notes and the download section. What else can be done so that users don't blow up?

blub 9y ago
The minimum should be a clearly presented option to turn off telemetry either during install or at first startup.
mel919 9y ago
Just a mere suggestion: you may look into how it's done in yeoman (https://github.com/dotnet/cli/issues/3093#issuecomment-220341285 https://github.com/dotnet/cli/issues/3093#issuecomment-22034...) and read this https://github.com/dotnet/cli/issues/3093 https://github.com/dotnet/cli/issues/3093 as there's lots of user input there.
cjsuk 9y ago
Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect. If you get an uptake of say 5-10%, if that's worth it then problem solved. If it's not then don't bother adding telemetry to start with. But before you do this, you have to ask the question: how did the software industry get by before the sudden rise of telemetry? It engaged the customer. I think a lot of cases it is used it is used as a substitute for engaging the customer.
- 9y ago

Piccollo 9y ago

"telemetry", what a euphemism.

shanselman 9y ago

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

yuhong 9y ago

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