5 ms·

How does this “kill the product for healthcare, finance and defence sectors”? This is part of the SDK tooling, it should not installed or run in the deployment

How does this “kill the product for healthcare, finance and defence sectors”? This is part of the SDK tooling, it should not installed or run in the deployment evnvironment. (If teletmetry is bad, running “dotnet restore” to download code from the internet is worse). If having telemetry in the development environment is bad too, then so was the “Visual Studio Customer Experience Program”. While that was opt-in, I would think that if telemetry was so dangerous that precautions would be taken to prevent it from being turned on. Precautions that would be at least as difficult as setting an environmental variable.

flukus 9y ago
> How does this “kill the product for healthcare, finance and defence sectors”? This is part of the SDK tooling, it should not installed or run in the deployment evnvironment. This will also be installed in places like the build server that may have extra permissions into the production environment. Often the firewall between production and development won't be as great as you think and all software has to be compliant because the developers will be dealing with real private data. > If teletmetry is bad, running “dotnet restore” to download code from the internet is worse "dotnet restore" could be hitting a local repository only, which is much more common in these environments. > If having telemetry in the development environment is bad too, then so was the “Visual Studio Customer Experience Program”. Typically it would be disabled, but things slip through the cracks, no matter how many precautions there are, which is why off by default is important. Aside from that, it kills trust. The developers don't even understand that this is a privacy violation and refuse to fix it, so when the next thing on the slippery slope comes along I don't expect them to appreciate the ramifications of it. Will compiler error codes be considered telemetry? How about exceptions? How about code metrics? I can't trust the dotnetcore developers to respect privacy.
- hudo 9y ago
  No, it does not kill trust. Maybe only in people who doesn't know how to configure and use CLI tools properly. Just disable this feature and move on!
  - alekratz 9y ago
    > Just disable this feature and move on! This implies that you're aware of the feature in the first place. One of the major points is that they don't make any sort of notice that telemetry was added in, turned on by default. There's a good example in the issue comment chain how Yeoman asks on first run if you want to send anonymous data.[1] [1] https://cloud.githubusercontent.com/assets/361677/15396939/3b97f800-1dac-11e6-96a8-c2325b004faf.png https://cloud.githubusercontent.com/assets/361677/15396939/3...
    - zamalek 9y ago
      They do, the first time you run dotnet.
- zamalek 9y ago
  > "dotnet restore" could be hitting a local repository only, which is much more common in these environments. You have to do this as part of your configuration. Alongside that configuration, you can change a single environment variable to turn telemetry off. > but things slip through the cracks I don't see how negligence is a valid counterargument. You could use the external repository by mistake and do far more damage. Are you more likely to forget about the the telemetry opt-out? After all this fuss I doubt it. The root comment also claims that Microsoft refuses to engage and allow the removal of it. The environment variable exists, Microsoft has clearly engaged and allowed the removal of it. This comment chain is FUD. Finally, if you really care about privacy this much you should be building things from source. This applies to .NET Core as much as it applies to GCC. .NET Core is open source, so this is absolutely possible to do.
  - svick 9y ago
    > Finally, if you really care about privacy this much you should be building things from source. […] .NET Core is open source, so this is absolutely possible to do. It's not that simple. Until recently, you had to have .Net Core installed to build .Net Core. There is now a way to build from source (https://github.com/dotnet/source-build https://github.com/dotnet/source-build), but it only works on Linux.
Const-me 9y ago
> How does this “kill the product for healthcare, finance and defence sectors”? Here's an example for healthcare: https://github.com/dotnet/cli/issues/3093#issuecomment-333896396 https://github.com/dotnet/cli/issues/3093#issuecomment-33389...
- oaiey 9y ago
  In healthcare software development you do risk analysis as a daily exercise. Mitigating this is so easy. In this Github comment the only issue is a scared customer management (how I read it), which in my opinion has no experience in handling audit findings or software development. Stopping CIL (or CLI) projects because of this is ridiculous and shows a lack of professionalism. I am in healthcare with multiple active development stacks (Java, Node, .NET, Python, ..) and in this regards I worry more of the Cordova/Node apps with their 1000s of npm dependencies which some of them do not even have a public source code repo and/or intentional anonymous author and/or without a license. Analyzing who is calling home there is a monumental task compared to the pretty uniform .NET or Java stacks.
  - Const-me 9y ago
    I agree the lab management overreacted in this particular case. If I were them, I’d ask the author of the comment to fork that repo disabling telemetry, and probably implement some automatic verification tool/tests to make sure no parts of the software stack call home. However, I can also understand the reason for the management’s paranoia. Besides that HIPAA law, it’s also the fact that if your genome gets leaked, you can’t change password/order another card like with the traditional IT data leaks. Probably, they view the data leak risk as an existential risk for their whole company.
    - oaiey 9y ago
      That is true. But in that level of paranoia I would argue they should stop using software :). In healthcare and other regulated environments they can shut you down for months or years because of your handling of audit findings. But you get findings because an employee missed his badge, hold open a door for an auditor or has the wrong training records. But there are finding severities, risk analysis and capa handlings to deal with them. Handling this case is easy. My argument is, when you are in healthcare and you cannot deal with audits and their outcome, stop being there.

flukus 9y ago

> How does this “kill the product for healthcare, finance and defence sectors”? This is part of the SDK tooling, it should not installed or run in the deployment evnvironment. This will also be installed in places like the build server that may have extra permissions into the production environment. Often the firewall between production and development won't be as great as you think and all software has to be compliant because the developers will be dealing with real private data. > If teletmetry is bad, running “dotnet restore” to download code from the internet is worse "dotnet restore" could be hitting a local repository only, which is much more common in these environments. > If having telemetry in the development environment is bad too, then so was the “Visual Studio Customer Experience Program”. Typically it would be disabled, but things slip through the cracks, no matter how many precautions there are, which is why off by default is important. Aside from that, it kills trust. The developers don't even understand that this is a privacy violation and refuse to fix it, so when the next thing on the slippery slope comes along I don't expect them to appreciate the ramifications of it. Will compiler error codes be considered telemetry? How about exceptions? How about code metrics? I can't trust the dotnetcore developers to respect privacy.

hudo 9y ago
No, it does not kill trust. Maybe only in people who doesn't know how to configure and use CLI tools properly. Just disable this feature and move on!
- alekratz 9y ago
  > Just disable this feature and move on! This implies that you're aware of the feature in the first place. One of the major points is that they don't make any sort of notice that telemetry was added in, turned on by default. There's a good example in the issue comment chain how Yeoman asks on first run if you want to send anonymous data.[1] [1] https://cloud.githubusercontent.com/assets/361677/15396939/3b97f800-1dac-11e6-96a8-c2325b004faf.png https://cloud.githubusercontent.com/assets/361677/15396939/3...
  - zamalek 9y ago
    They do, the first time you run dotnet.
zamalek 9y ago
> "dotnet restore" could be hitting a local repository only, which is much more common in these environments. You have to do this as part of your configuration. Alongside that configuration, you can change a single environment variable to turn telemetry off. > but things slip through the cracks I don't see how negligence is a valid counterargument. You could use the external repository by mistake and do far more damage. Are you more likely to forget about the the telemetry opt-out? After all this fuss I doubt it. The root comment also claims that Microsoft refuses to engage and allow the removal of it. The environment variable exists, Microsoft has clearly engaged and allowed the removal of it. This comment chain is FUD. Finally, if you really care about privacy this much you should be building things from source. This applies to .NET Core as much as it applies to GCC. .NET Core is open source, so this is absolutely possible to do.
- svick 9y ago
  > Finally, if you really care about privacy this much you should be building things from source. […] .NET Core is open source, so this is absolutely possible to do. It's not that simple. Until recently, you had to have .Net Core installed to build .Net Core. There is now a way to build from source (https://github.com/dotnet/source-build https://github.com/dotnet/source-build), but it only works on Linux.

Const-me 9y ago

> How does this “kill the product for healthcare, finance and defence sectors”? Here's an example for healthcare: https://github.com/dotnet/cli/issues/3093#issuecomment-333896396 https://github.com/dotnet/cli/issues/3093#issuecomment-33389...

oaiey 9y ago
In healthcare software development you do risk analysis as a daily exercise. Mitigating this is so easy. In this Github comment the only issue is a scared customer management (how I read it), which in my opinion has no experience in handling audit findings or software development. Stopping CIL (or CLI) projects because of this is ridiculous and shows a lack of professionalism. I am in healthcare with multiple active development stacks (Java, Node, .NET, Python, ..) and in this regards I worry more of the Cordova/Node apps with their 1000s of npm dependencies which some of them do not even have a public source code repo and/or intentional anonymous author and/or without a license. Analyzing who is calling home there is a monumental task compared to the pretty uniform .NET or Java stacks.
- Const-me 9y ago
  I agree the lab management overreacted in this particular case. If I were them, I’d ask the author of the comment to fork that repo disabling telemetry, and probably implement some automatic verification tool/tests to make sure no parts of the software stack call home. However, I can also understand the reason for the management’s paranoia. Besides that HIPAA law, it’s also the fact that if your genome gets leaked, you can’t change password/order another card like with the traditional IT data leaks. Probably, they view the data leak risk as an existential risk for their whole company.
  - oaiey 9y ago
    That is true. But in that level of paranoia I would argue they should stop using software :). In healthcare and other regulated environments they can shut you down for months or years because of your handling of audit findings. But you get findings because an employee missed his badge, hold open a door for an auditor or has the wrong training records. But there are finding severities, risk analysis and capa handlings to deal with them. Handling this case is easy. My argument is, when you are in healthcare and you cannot deal with audits and their outcome, stop being there.