There are enough examples of companies doing terrible stuff that concerns are entirely understandable.

Let me take the opportunity to say:

1) YOU ARE NOT OUR PRODUCT! 2) Our goal is to use telemetry to help us make better decisions about what will help our customers (as with with projects, only a subset of users are active in our community feedback process) 3) We are super open about the telemetry (including going through the PowerShell community review process) and publish all the data. More details here: https://devblogs.microsoft.com/powershell/new-telemetry-in-p...

Here is all the telemetry: https://aka.ms/psgithubbi

Jeffrey Snover [MSFT]

Thanks for taking the time to address this (And a great thanks for Powershell ! Which regardless of some reservations about its language is a great technology and a major leap forward in terms of soundness and productivity in the IT sphere)

I fully appreciate the importance of telemetry, crash reports etc. for product owners and teams, and am not under the impression that it is currently being abused by msft.

However, as telemetry is a very general functionality and by their nature both company policies and software products are subject to frequent changes and given the many example of abuse by some companies quite comparable to msft in terms of their scope of impact and business incentives I don't think its usefulness overrides the principal concerns regarding the practice of including it enabled by default with distributed products even when disclosed.

Anything that does not require an explicit user action to enable telemetry imo falls short of the desired ethical standard of respect for user agency that should exist in an ecosystem that wishes to foster trust between vendors and users and this goes double for open-source projects.

Given that PowerShell is Open Source, you can exactly see the telemetry code. Before we added the first bit of telemetry or when we needed to add more, we published RFCs for community feedback disclosing what we were collecting and why. https://github.com/PowerShell/PowerShell-RFC/blob/master/5-F... and https://github.com/PowerShell/PowerShell-RFC/blob/master/2-D.... We recognize that some users don't want to send any, which is why we made it simple to disable (completely!). However, opt-in telemetry also means we would receive very little making it not useful. Before any telemetry is added, we also go through an extensive privacy review to ensure no personally identifiable information is included (therefore all our telemetry is anonymous).

The average user cannot be assumed or expected to be following powershell blogs or to have gone through the community discussions or to have read the RFCs and definitely not to have individually reviewed the source code, they would just download and run powershell while not being aware that this functionality even exists and be dismayed once they learn about it. In this onboarding scenario the current form does not even satisfy good faith disclosure criteria much less can be said to constitute an informed consent.

A trustworthy way to do this would have been to have the user presented with a prompt upon first interactive run explaining them the importance of the telemetry to msft with a link to relevant documentation and privacy policy and a Y/N selection, anytime the collection logic changes or a new datum is added the consent needs to be renewed, and if it turns out that under those conditions most users choose not to enable it than it will probably be the single most actionable user input msft receives from/about its telemetry practices.

> Anything that does not require an explicit user action to enable telemetry imo falls short of the desired ethical standard of respect for user agency that should exist in an ecosystem that wishes to foster trust between vendors and users

Personally, I disagree. I think that telemetry should be clearly disclosed (as any kind of 'phone home' functionality), so as to give user full knowledge of what will run on their machine.

In this sense something negative about telemetry is that it is not uncommon to find it turned on by default after an update (I have no idea whether this applies to Microsoft), or when in situation like the recent gitlab blunder they decided to have third-party scripts for telemetry.

For anything else active-by-default telemetry is in the same category as adding half a dozen random dot-files in your home directory (which often is not configurable).

> ... this goes double for open-source projects.

Again I disagree, with free-software you have the right to run a telemetry free version of the product and with open-source you have the ability to actually inspect what the telemetry is doing.

The place where telemetry is sort of shady is the gray area that is neither free/open software not enterprise agreements with legally binding reasonable contracts; which includes for example Windows 10.

Well at this point it is not even clearly disclosed, as I have just downloaded a release .tar.gz from github, unpacked it, ran it and saw no mention of telemetry or its opt-out options.

The free software vs. open-source distinction is quite subjective but irrelevant here - Powershell source code is released under the MIT license which allows anyone to produce a modified telemetry-free build but sensibly does not obligate the authors to provide one themselves, hence my original comment.

There is VSCodium, I'm not aware of others.

Thanks ! Was not aware of VSCodium

Although it appears to be a binary-only download claiming to be free of telemetry and non-floss code, it does not share the fork itself, what am I missing here ?

EDIT: "This is not a fork. This is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration."