When admins discovered the PowerShell team proposal for additional telemetry, some bristled; however, the data collection could mean a better management language for IT pros.
Privacy and security remain reoccurring concerns that IT pros stress when vendors and developers propose telemetry. PowerShell users responded no differently when the PowerShell team posted a thread on GitHub in February 2019 to get community feedback about adding a telemetry API.
The proposed PowerShell telemetry data collection would transmit information on the PSEdition, platform, application, session type and commands used with the intention to better develop the language to address the needs of its users. The team wants to track statistics including how PowerShell Core usage is growing, what issues users run into in PowerShell Core and what versions and services need continued support.
In light of complaints about the opt-out option of PowerShell telemetry, the team plans to create a more intuitive way users can decline to be part of the data collection. The PowerShell team stated that it would use the data to find trends, not to collect individuals' data. In addition, the team would make collected data available to the community.
SearchWindowsServer advisory board members offered their thoughts on the usefulness of PowerShell telemetry and what the team would need to do to achieve a balance between collecting data and maintaining the community's trust.
Telemetry should always be opt-in
Tim Warner
Microsoft collects an enormous volume of telemetry data from its customers. Telemetry streams improve the product, and Microsoft states openly they are not used to spy on customers. The PowerShell team at Microsoft has also been discussing adding a telemetry API to the language. This API wouldn't be for Microsoft's use, per se, but for PowerShell scripters.
Imagine we wrote a PowerShell module that automates OS deployment. Wouldn't it be helpful if we could add telemetry collection to the module so we can receive usage details from those who use the module?
In light of complaints about the opt-out option of PowerShell telemetry, the team plans to create a more intuitive way to do so.
Again, the point here isn't spying or privacy invasion. By collecting telemetry from users of our PowerShell modules, we can better identify usage patterns and error messages, which we can use to guide and improve our development process.
The big question is how to implement the telemetry. I'm 100% against any default-enabled telemetry feature, particularly when it's implemented without user consent.
What I would recommend the PowerShell team does is implement telemetry functionality in an informed, opt-in manner, like Microsoft does with the Azure command-line interface (CLI).
At first launch, Azure CLI asks the user whether she agrees to telemetry data collection.
The only change I would recommend to Azure CLI is that I think the default answer should be No instead of Yes to preserve the privacy of users who blindly press Enter past confirmation prompts.
Telemetry has gotten a bad rap of late with various vendors accused of scooping up data without the option to truly opt out, which is the case in Microsoft Windows 10. As far as I am aware, Microsoft is the only vendor that does not give the average user the ability to fully opt out of telemetry.
Microsoft does a huge disservice to the privacy-conscious amongst us by taking away our ability to choose in real terms what we share. Therefore, anything it does with telemetry is going to be looked upon with great suspicion, tainting any company that decides to use it.
Your laptop or desktop holds a great deal of information about your life, your habits and, sometimes, your financial information or other sensitive material. Vendors and marketers would love to gather such information on unwitting users.
Telemetry can also be good when exercised with appropriate caution. The option to allow vendors to collect usage data is neither good nor bad. Giving the option to developers enables them to potentially build better products using a standardized framework and set of tools. As long as people have the clear-cut ability to choose what data is collected and the usage is transparent, I don't see an issue with it. It comes down to the simple question of trusting the vendor to do the right thing. With some vendors that I have used for many years and trust, I have no issues. Others, such as Microsoft, I do not trust and will opt out wherever possible, even going so far as to move OS ecosystems.
Telemetry without transparency or data control and opt-out options has crossed the privacy redline and potentially creates liabilities for those vendors, not just the person using the telemetry. I would expect Microsoft to put legal framework around this tool that is reinforced in the actual code to give people choices. Putting it front center with options of Yes or No would work well. Without such a framework, the whole tool set is open to misuse and abuse.
While PowerShell is still very much a closed framework at the moment, I can't help wondering if Microsoft will write the legal framework around this tool to ensure that it can also collect and use this data.
It all comes down to clarity of usage and manageability options, enabling users to make up their own minds if they want to share what could be pretty private data with vendors or, even worse, third-party data aggregators.
PowerShell Core 6 versions have always had telemetry that automatically reports which OS and PowerShell version you use when you start a PowerShell session. You must choose to opt out of this telemetry being collected.
The proposals significantly expand the telemetry being collected. Some of it, such as the use of experimental features, I can see as being especially useful to the PowerShell team, but I question the need for much of the proposed telemetry. Reporting on modules and commands used is going to generate so much noise that detecting a worthwhile signal will be particularly difficult.
Richard Siddaway
The other issue is that the telemetry will be turned on by default. This is the wrong way round. You should have to opt in to the level of telemetry being proposed. I suspect that many, if not most, PowerShell Core 6 users aren't aware that telemetry is currently being collected. The information is in the release notes, but I'd be interested to know how many users actually read them. A lot of organizations don't allow information to be sent externally, which means that administrators will have to turn off telemetry wherever PowerShell Core 6 is installed. That's more work for the admins, which will only slow the adoption of PowerShell v6.
The proposal to create an API for module authors to collect their own telemetry takes things too far. There is the chance that a significant overhead could be put on your PowerShell session if you have multiple modules sending telemetry to multiple different places. I suspect this will be the point at which many users will turn off all telemetry.
I can see why the additional telemetry Remote Function Call has been created, but I think it's fundamentally flawed in its current state. If there is a real need for this level of information, then telemetry should be performed on a number of levels -- basic information as at the moment, modules loaded and commands executed, for instance. Each level should be set so that you opt in to it rather than having to opt out. The default should be no telemetry is sent at all.
Tim Warner
Stuart Burns
Richard Siddaway
