-
Notifications
You must be signed in to change notification settings - Fork 129
RFC0036-AdditionalTelemetry #158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks useful and very above-board. 😊
A few ideas came to mind reading through that may or may not be useful at some point. 🙂
With additional telemetry, will the performance/user experience be impacted ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, this is one way to gather necessary data for the PowerShell team and the community to prioritize work to encourage PowerShell Core adoption. I appreciate your efforts.
I am not in favor of it. Most telemetry consumes unnecessary bandwidth as well as disk space especially if my internet connection is lacking. There is also the privacy element. |
@SherSlick it seems the total amount of telemetry will be pretty small from the items listed in the RFC, barely approaching 1KB, if that, on a startup. It's basically some numbers, a couple GUIDs (if opted in to identifying data only), and that appears to be about it. Do you have specific objections? |
@vexx32 the size of the payload being minimal is not the only factor. When I installed Power Shell on my Macintosh over a year ago it was making NUMEROUS DNS queries in a small period of time. 1) this seems to be bad form as getting DNS for every call is just wasteful 2) how well would it handle seconds of latency for replies? |
@SherSlick Definitely understandable concerns, and ones that should be addressed by the RFC from a technical standpoint. Appreciate you taking the time to bring it up! 😄 @SydneyhSmith can you speak to those concerns? |
I stopped using Windows bc of telemetry, so no. I don't like that. |
To address PowerShell/PowerShell#9006 we could collect cropped (for privacy) version of ErrorRecord. |
I support what this RFC is trying to accomplish- getting more usage data to the PowerShell team so they can better prioritize future plans. However, opt-in should be the default for numerous reasons: privacy concerns, performance concerns, forcing someone who doesn't want to send this data to opt-out each and every time they install powershell on a new system including containers, etc. TL;DR- +1 if this is opt-in, I'll gladly participate. -1000 if this is the default behavior. |
@SydneyhSmith someone in the PowerShell slack/discord channels brought up that it should be configurable domain-wide with a GPO if possible, to facilitate orgs who are more strict on privacy/telemetry. |
No matter what you want to collect it should be an opt-in or a way to totally disable it as, in most corporate environments, telemetry is generally required to be disabled. As per company security departments are generally against this. |
@lwajswaj It is already implemented. https://github.com/PowerShell/PowerShell#telemetry |
Something to consider: if this is opt-in, will that not skew the data to the point of it being pointless? If it's opt-out, the negative association with telemetry is likely to hurt PowerShell adoption significantly. Tech people are far more likely to be concerned with privacy to the point of anything remotely like "phoning home" being a non-starter. I appreciate the goals here, but I don't believe this is a good idea. |
@bgshacklett I'm sure if you can come up with a better way of obtaining data that can help guide the future development efforts of PowerShell Core in a way that avoid those issues, the team would be willing to listen. 😄 I think having the default be collecting only non-identifying telemetry is the only reasonable compromise here, unless you would prefer the PS team to have to constantly make guesses about where to divide their time, and give up hope on them ever having sufficient manpower to properly manage everything they want to be able to do. 🤷♂️ |
…ccepted/RFC0036-AdditionalTelemetry.md
No description provided.