FYI, from the announcement. Probably the most important part at the end, italicized by me. Also note (elsewhere) that licenses are MIT and Apache2:
.NET Core Tools Telemetry
The .NET Core tools include a telemetry feature so that we can collect usage information about the .NET Core Tools. It’s important that we understand how the tools are being used so that we can improve them. Part of the reason the tools are in Preview is that we don’t have enough information on the way that they will be used. The telemetry is only in the tools and does not affect your app.
Behavior
The telemetry feature is on by default. The data collected is anonymous in nature and will be published in an aggregated form for use by both Microsoft and community engineers under a Creative Commons license.
You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running.
Data Points
The feature collects the following pieces of data:
The command being used (e.g. “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
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.
I choose to ignore this post so five weeks from now I can write an outraged "Microsoft is TRACKING YOU" article on Medium that will garner me praise and upvotes.
And 100x quicker than setting the clearly documented environment variable that disables the feature.
> You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running.
If it were opt-in, they'd collect significantly less data, and the data they do collect would likely by heavily skewed. Microsoft could be misled by the poor quality of data collected, and an opt-in system could actually be worse than not collecting any data in the first place.
The way I see it, at the end of the day, the decision for Microsoft is really between not collecting data and an opt-out system. If Microsoft chooses not to collect data, then all developers have to live with tools that improve slowly and have issues (possibly security related that could be maliciously abused) that are not fixed as quickly as they could be.
If Microsoft chooses an opt-out system, they can collect the data they need to make sure their tools are working optimally and as intended. Some developers may not be comfortable sharing how they use Microsoft's tools even with no personally identifiable information collected. These people can opt-out while minimally compromising the quality of the data collected. Additionally, the tools are open source, so any developer that's skeptical of how and what data is being collected by the tools can verify Microsoft's claims.
Those are the two options I see. To me, the cost/benefit of the second option greatly outweighs the cost/benefit of the first for all involved. By not collecting data, security issues that could actually compromise your privacy could go unfixed for longer. By collecting data through and opt-out and open source system, Microsoft can fix issues ASAP and developers can verify that data is collected in way that preserves their own privacy.
It seems like a lot of people are knee-jerking to the idea of collecting data through an opt-out system and not actually weighing the cost/benefit of the realistic options. Can you explain how not collecting data has a lower practical cost/benefit ratio than an opt-out and open source system?
That doesn't refute my point. No data collection still leaves a greater probability of issues being left unresolved for a longer period of time. Also, the code is open source. You can see exactly what data is being collected.
To address your point, it's not possible to be aware of the benefits you're missing out on without data collection.
For me the issue comes down to whether or not Microsoft does anything useful with this data (probably not, if 20 years of NVIDIA blue screen driver failure logs, Windows 8 and OneDrive are any example of how 'big data' impacts Microsoft product quality) versus how many comments I have to read where joeblow52 is personally offended that Microsoft dares to learn what his compile time plus 999,999 other compile times, divided by a million, equals.
How, exactly, are you thinking that Microsoft is going to fix nVidia's buggy drivers? They can collect all the data they want, but at the end of the day, it's nVidia's driver.
I worked there. Ways we solved these sorts of problems include: hardening the other side of the API/HAL when appropriate/possible, simplifying the driver model so that mere mortals could write drivers, writing our own drivers and overwriting known buggy ones for companies that couldn't get their shit together (usually network vendors), adding workarounds to the OS not to use certain features of certain cards, flying external engineers to lavish parties and our driver development labs and compatibility labs and providing one on one engineering development assistance from senior kernel developers, providing free testing of drivers for known problems before release, rolling fixed drivers into Windows updates, providing marketing funds as reward for fixing problems, and not using NVIDIA in the Xbox 360 after using them in the original Xbox as punishment because they were personally responsible for over 80% of blue screens in Windows for the preceding five years.
Sadly the motivation was often to ignore the data or watch it get spun by some jackass with the exact wrong agenda. It's just software, there's always a way to fix things if you really want to.
I just installed these tools and it tells you on first invocation that telemetry is enabled and how ti disable it. I think that buys a little bit of good will. I am also opposed to telemetry by default, but I understand it, and appreciate the opt out message being presented clear and up front.
Microsoft is looking to do more data-driven design; this is the reason for all the telemetry in Windows as well. Raymond Chen pointed out an example where a button was removed File Explorer (prime real-estate) because the telemetry showed that hardly anyone ever pressed it.
It's unfortunate they are so tone-deaf about the PR implications in Windows.
We have removed all the weapon deployment buttons from our nuclear subs, silos, and bombers, because telemetry shows that they are typically only pressed during unit testing.
Since we only have two recorded events of someone deploying a nuclear weapon in a real-world scenario, it should be safe to relocate those buttons off the main console, and just use the auxiliary functions button, behind the kick panel, next to the row of DIP switches used for selecting the button press function. Since "reorder coffee pods" was the last auxiliary function to be added, "launch nukes" will be next, so make sure you double-check those switches before pushing, coffee drinkers!
You're joking but I'll give a serious reply to why your analogy is off. This is why they have war games. The telemetry from those games would be included in the analysis.
My point was that user interface patterns do not always indicate the importance of the control, because there may be multiple modes of operation (such as "Standby", "War", "War Game", and "Readiness Drill") that might not be obvious--or even apparent--from the raw button-press numbers.
You want the "War Game" telemetry to count for the "War" design, but you can't really tell which is which without having additional data that you shouldn't be allowed to see. If you detect "casual user" and "programmer" modes in your OS, the user shouts, "I don't want my computer knowing (and sharing) that much info about who I am!"
Even though most people aren't likely to ever need to use a fire extinguisher, you really want that interface to be simple and accessible. If you decide that because no one ever used this particular fire extinguisher, it doesn't need to be there, that's a decision that could make the difference between life and death. Moving a button on a form doesn't seem quite that serious, but it could still cause people to lose time or money, which adds up across all the people using the software.
I know this is just meant in jest, but because the weapon deployment buttons are something you never want to be pressed on accident, ideally you really do want to obscure them behind layers and layers of user interaction.
If anything we had the problem of them not being obscured enough for a while (if the story of the launch codes being 00000000 across the board is true).
I always suspected that there was probably significant overlap between users of macros and users who opted out of telemetry. Lesson learned: leaving "yes" checked from now on.
Data collected by a neutral third party without conflicting interests pushing for creative monetization opportunities that's responsible for sufficient annonymisation/aggregation before releasing the data?
The Ribbon is, in my opinion, the use interface equivalent of a broken pull tab on a can of corn. I know it is there, I know that I'm supposed to use it, but I can't because it is broken.
Backspace is "back" not "up a folder level" as far as I am aware. This is consistent with web browsers - and indeed the conceptual meaning of "backspace" (go back 1)
So random question: I like when MS people come out and engage the community like we are responsible adults and not like moronic children who need hand-holding and cannot decide for ourselves.
Since we all know the famous "Open Source is cancer" reign of Balmer oft-joked of here, I assume the related issue at hand is culture shift is good and less of a concern now, as opposed to a few years ago. But I am super happy when people like you drop by.
How do people like us on HN, Reddit, and Ars get you and those like you to say, see daveguy's manager[s], we will reconsider our avoidance of the MS tech stack because how daveguy did X?
Is this silly? I am not sure. But I wonder if I am the only one who wants people like yourself to thrive so MS keeps going in this direction.
The best way to make sure they (we, since I work at Microsoft) get the feedback is by finding out where the product is listening.
A lot of products have UserVoice set up, a lot of dev product teams (dotnet, asp.net, etc.) are looking for GitHub issues.
For Windows 10 I'd recommend using the Windows 10 Feedback Hub - if you hate something about Windows 10, post feedback in the Feedback Hub before you uninstall it.
There are lots of us who see your comments on HN / Reddit / Slashdot / etc. but having been part of the Microsoft ecosystem (both inside and out of Microsoft) for many years, I can tell you that there's a huge difference between "I've seen some unhappy comments about X" and "Our feedback numbers show 68% of users want us to improve feature X". Also, specifics are important - a detailed issue report with repro steps and recommendations for what you'd like to see work a whole lot better than "@drunkvs LOL VS suxxxx ikr!!!"
Also, just because I'm an ocd fact checker, Ballmer technically didn't say "open source is a cancer". He said that Linux is a cancer, referring to the strong copyleft license requirements (https://web.archive.org/web/20011211130654/http://www.suntim...). [yes, I very well know that you can run software on Linux without that software being GPL. I'm writing this from Red Hat DevNation :)]
Regardless, I can tell you that our current CEO and everyone I work with is excited about writing great software that runs everywhere.
Well I tried that once or twice in the Connect era. But if you say it will make a difference this time, next time I have issues I will contribute.
And yeah, that cancer line was meant to snarky and cute, not factual. It does not really matter more than me indicating the obvious, that this is a big culture shift if you look at the timeline. I think MS has ways to go too, and the long game is where we will see how it fares, but I want to make sure we encourage the good. Or it will languish, as "no one cared after a while."
Yeah, please try again. The problem with a lot of Connect programs is that they were tied to a specific release (MonkeyManager Pro 2008) so bugs that didn't make the cut for the product release just got lost in space (not picked up for MonkeyManager Pro 2010). Part of the reason was that there were always internal bug tracking systems, which was what the dev team was really working from day to day, and these other systems were just inputs to that.
If you look at any of the projects that are on GitHub now, the public issues list is the issues list. You can see all the dev comments, scheduling via labels, pull requests, code reviews, etc.
For products that aren't on GitHub, public issue lists like UserVoice have still been a big improvement (in my opinion) because they usually keep the bugs / issues / feedback around until it's fixed, and the votes accumulate so the important issues keep bubbling up.
I had a couple of reports on Connect related to crashes in Edge on Xbox disappear as part of a migration - the best I can work out they've become private/internal. I'm assuming those kinds of things are going to UserVoice and not GitHub but is there some way I can find out what happened in the end?
I am looking into ways to move everything we do off of MS Tech completely because I don't trust their direction with Windows 10.
I posted this because I thought it was an interesting and relevant part of the announcement. If MS was this straightforward and transparent with Win10 (allowing easy disabling of telemetry and the option to control upgrades at all levels) then I wouldn't be looking at alternatives. Although off by default would be better, but they would get approximately zero feedback with that. Best would probably be ask on install with a checkbox easily unchecked.
Whoever decided their .net tools telemetry and messaging needs to be in charge of that aspect across all products.
You and I are on the same page. What concerns me is that really the best work on securing core internals of the OS from long standing problems, such as strengthing LSASS and SAM against pass-the-hash with virtualized, isolated processing shielding and HW age I will be forced to it already. All the talk of Corona scares me, and not even CIS and the big players have guidance since MS has the new attitude of "just trust us already." Their announcing, even with Enterprise SKU, you cannot disable Windows Store, worries me. In my personal life, Windows is something I hardly ever use. But work and Windows 10, being shoved down into the deskop market, is scary. The Cred Guard stuff and improvements are wonderful, but their increasingly we're the cloud and you're the peon attitude also terrifies me.
Well, until it is not interesting for them as a PR strategy. I do not want to lose these people when the pendulum swings back the other way.
And you and I check Github. That does not mean anyone being engineering managers care. I am curious what else we can do beyond starring GH repos. I do that, I just do not like my lazy armchair form of support and worry I will lose a culture shift at MS I have quickly fallen in love with after years of reviling the company as a whole, short-sighted or not.
Purely subjective and observational... but I had a few MS guys go out of their way to communicate a bug in probably the most popular node.js driver for MS-SQL (tedious), and it was interesting... There wasn't as much updated on the Github issue, but I was included in on some of the communication issues, and they were pretty open about it.
The person that had poked in was iirc, and Azure developer in MS, not from the MS-SQL team. There are plenty of developers at MS that do follow various GH projects (as happens everywhere else) and will get the right people involved when they see things.
I would presume that by pushing these kinds of projects (.Net Core, etc) out to github, and even the documentation likely won't see things close off any time soon, and not without losing more mindshare than Oracle has caused people to move away from Java.
I don't think the previous comment is suggesting it is bad. I think they're trying to stave off any "OMG! MS is looking at your porn!" posts, by highlighting the privacy policy of the telemetry; which sound reasonable to most people.
Thank you. I wasn't suggesting it is necessarily bad. It looks like the openness and ease of disabling is being handled much better here than with Win10.
However, the option to disable on install (checkbox prompt for preference) would be much better. This is an improvement over the Win10 approach.
Sorry if I took it the wrong way and jumped the gun too soon.
Microsoft is by no means an example of sainthood, but many in the HN community tend to only criticize it, while closing the eyes to similar actions of companies that are closer at heart.
Yes. It's bad when Microsoft does it this way because it's opt-out. IntelliJ/Android Studio prompts you and asks you your preference first. I think Eclipse is opt-in but could be mistaken.
Homebrew is opt-out post-install by setting a flag as well (no option or warning pre-install). But they do remind you afterwards that they are tracking and give you a link to learn how to disable it.
As long as no data is sent until first use (giving you a buffer to opt-out), I don't have an issue with this.
The telemetry was in the original preview release of the tools with RC2. It can be turned off and I believe it won't be in the final stable CLI tools release, but that may change.
It's the same with VS and VS Code (and Atom too). There has been a move from opt-in (for older versions of VS) to opt-out. Although I do still see connections to MS domains with all the customer experience stuff turned off.
I simply don't want to be tracked in any form regardless of whether it collects my personal data. Yet it seems more and more impossible these days. It's like "If there's nothing about collecting your personal data, then you should compromise".
Sorry to tell you this 4684499, but this website and most every other website on the internet knows how many page views they have and the IP addresses that are used to get to their website, etc. ...all because they have telemetry on the server. It's how they tell if something is working or not working. Not all telemetry is bad.
Well, it does track, but it doesn't necessarily collect the data and use it to profiling users. I just don't like to be experimented like a little white mouse in a mouse lab, regardless of whether it's for good or bad.
.NET Core Tools Telemetry
The .NET Core tools include a telemetry feature so that we can collect usage information about the .NET Core Tools. It’s important that we understand how the tools are being used so that we can improve them. Part of the reason the tools are in Preview is that we don’t have enough information on the way that they will be used. The telemetry is only in the tools and does not affect your app.
Behavior
The telemetry feature is on by default. The data collected is anonymous in nature and will be published in an aggregated form for use by both Microsoft and community engineers under a Creative Commons license.
You can opt-out of the telemetry feature by setting an environment variable DOTNET_CLI_TELEMETRY_OPTOUT (e.g. export on OS X/Linux, set on Windows) to true (e.g. “true”, 1). Doing this will stop the collection process from running.
Data Points
The feature collects the following pieces of data:
The command being used (e.g. “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
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.