
Microsoft/.Net Foundation added telemetry to the dotnet command line last year - mel919
https://opinionatedgeek.com/Blog/2017/3/26/your-tools-shouldn-t-spy-on-you
======
orf
For reference, they collect[1]:

    
    
        The command being used (for example, "build", "restore")
        The ExitCode of the command
        For test projects, the test runner being used
        The timestamp of invocation
        The framework used
        Whether runtime IDs are present in the "runtimes" node
        The CLI version being used
    

I'm actually OK with this to be honest.

Here is the telemetry code itself:
[https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f95830...](https://github.com/dotnet/cli/blob/5a37290f24aba5d35f3f958300aa20329e5ccaa7/src/dotnet/Telemetry.cs#L92-L104)

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

1\. [https://docs.microsoft.com/en-
us/dotnet/core/tools/telemetry](https://docs.microsoft.com/en-
us/dotnet/core/tools/telemetry)

~~~
bjpbakker
> For reference, they collect

That's not all that matters. IMO the real decision is: do you /trust/ MS ? Do
you trust that they anonymize collected data and that they won't secretly
change collected data? Do you trust future MS with that information.

> I'm actually OK with this to be honest

That's perfectly fine if you trust them. Many people don't. Personally I
wouldn't trust any dev tool that uploads my usage.

~~~
lightbyte
>That's not all that matters. IMO the real decision is: do you /trust/ MS ? Do
you trust that they anonymize collected data and that they won't secretly
change collected data? Do you trust future MS with that information.

You don't need to trust them. The telemetry code is open source AND they
release the aggregate data it collects for anyone to use/inspect.

~~~
msla
If it's completely open, how do they keep it from being spammed?

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

------
romanovcode
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
I'm not the author of the blog post. I think you're comparing apples and
oranges, also this kind of reasoning is an example of "tu quoque" logical
fallacy.

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

------
marenkay
What's with this exaggerated blog post?

1\. It was announced in the open in June 2016 that .NET Core includes
telemetry:
[https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcin...](https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-
net-core-1-0/) 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

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

[1] [https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-
weve...](https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve-learned-
from-net-core-sdk-telemetry/)

~~~
shakna
The data is also public, at:

[https://dotnetcli.blob.core.windows.net/usagedata/dotnet-
cli...](https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-
usage-<YEAR>-q<QUARTER>.tsv)

So, the latest would be:

[https://dotnetcli.blob.core.windows.net/usagedata/dotnet-
cli...](https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli-
usage-2017-q2.tsv)

~~~
0x0
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
They don't include command line arguments (yet). They include the command verb
(dotnet [build/restore/etc]) that was ran.

~~~
0x0
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
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.

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

~~~
cjsuk
Let's just be clear that it's entirely OK to add telemetry to your code. The
objection here from most of us I suspect is that it is on by default. If you
package a tool so it does an unattended installation in some way i.e. via a
package manager etc, the default state of the code should be opt-out of
telemetry. If you have a GUI installer, ask the user if they want it and
outline the benefits and what you collect.

If you get an uptake of say 5-10%, if that's worth it then problem solved. If
it's not then don't bother adding telemetry to start with.

But before you do this, you have to ask the question: how did the software
industry get by before the sudden rise of telemetry? It engaged the customer.

I think a lot of cases it is used it is used as a substitute for engaging the
customer.

~~~
swsieber
Indeed. Though on-by-default telemetry gets a different set of data than
engaging with the customer.

If adding telemetry is faster and easier than engaging with the customer, then
you'll see projects that add telemetry that wouldn't otherwise have the
bandwidth to engage with the customer.

In general, I think the best way to go is to ask in the installer or initial
setup, whether you want to send telemetry, and have a sane default according
to whether you gather potentially personal information (location? personal,
commands run (without args), not personal).

Example Prompt: Send telemetry (commands used, version) (y/n)[y]:

~~~
zabil
We've experimented asking users on install or initial setup. But most of the
time our tool runs in non interactive environments e.g. on a CI/CD set up
(install and execution).

An additional flag for non-interactive installs can solve the problem, but
that's a broken setup experience, someone has to look up the documentation
after a failure to install.

Turning it off by default in case of a CI/CD setup means losing most of the
data.

~~~
winthrowe
If you're setting up automated non-interactive installs, your job is to check
for install failures and consult the documentation; I know that's part of my
job.

I'd recommend a required installer flag forcing the user to make a decision,
but I'm a user who generally leaves telemetry on.

------
wereHamster
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
I'll just set the environment variable thanks.

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

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

------
staticelf
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
> and basically any site today does more intrusive telemetry

So the next version of Bash should have telemetry?

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

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

~~~
staticelf
Well yes, and it behaves as expected, don't it? They are very open with what
they are doing and you can build from the sources if you do not trust the
binaries.

The point is, I understand why people dont want telemetry. I don't. I think
they should ask before they do it, a lot of people are probably willing to
share the data. BUT I also understand why they are doing it and I think
they've done it in a good manner still.

You should also think about your expectations, one shouldn't have to expect
that every site is trying to track you.

~~~
shakna
My point is:

> and basically any site today does more intrusive telemetry

has absolutely nothing to do with a _local_ application.

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

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

------
RubyPinch
"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
_" 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?

------
Piccollo
"telemetry", what a euphemism.

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

------
yread
Should have [2016] added to the title

[https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin...](https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-
net-core-rc2/#net-core-tools-telemetry)

/s

------
0xFFC
tl;dr please?

~~~
dvfjsdhgfv
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.)

------
_pmf_
"Telemetry" ... nice spin.

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

