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
Here is the telemetry code itself: 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...
1. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry
Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience.
The data is anonymous and does not include command-line arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Hard to believe, but they used to sell products a while ago and had no telemetry.
If you want to see how it's done properly, look at OmniGroup: their apps have toggleable telemetry and it's off by default.
The other things being collected are:
* Geographical location
* Operating system and version
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.
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.
Why do you have to trust MS? You can read the source code to check for yourself whether sensitive information is sent. You don't have to take Microsoft's word for it.
Bear with me. This seems like the wrong question, but not for the reason you might expect. Rather, I think that it might be wrong because, even if Microsoft acts in completely good faith, it is damn near impossible to anonymise collected data properly [obligatory citation of the 'anonymised' AOL search data]. It doesn't matter whether I trust someone to do something if they (probably) can't do it.
It's not just independent devs that are using .net. And the name of the company appears often in the assembly.
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.
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]
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... 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
[1] https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...
https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...
So, the latest would be:
https://dotnetcli.blob.core.windows.net/usagedata/dotnet-cli...
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?
We are turning on telemetry in the next release for our open source tool. 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 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?
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.
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]:
OTOH nobody gets around a firewall which blocks all outgoing connections ;)
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.
I think they should ask people like Yeoman, but I don't think they deserve this much shit for such a small thing.
They are just ignoring to let the issue die silently.
"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?
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?
https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin...
/s
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.