[ptx]

PowerShell "sends basic telemetry data to Microsoft [...] about the host running PowerShell, and information about how PowerShell is used" [1].

And since it relies on .NET, that also requires its own separate opt-out for its telemetry. There might be other components, now or in the future, that also send data to Microsoft by default and would have to be separately discovered and disabled.

[1] https://docs.microsoft.com/en-us/powershell/module/microsoft...

[sandyarmstrong]

> And since it relies on .NET, that also requires its own separate opt-out for its telemetry.

Building a program with .NET does NOT cause that program to send telemetry to Microsoft.

You're thinking of the .NET SDK itself. Using PowerShell does not trigger any use of the .NET SDK.

Disclaimer: I work for Microsoft.

[ptx]

Ah, yes, my mistake. Although PowerShell sends its own telemetry, the additional telemetry from the .NET platform is only sent when you use the dotnet command [1] and, as a special case, not when you very carefully invoke it only "in the following format: dotnet [path-to-app].dll" and never e.g. "dotnet help".

However, presumably PowerShell requires at least the .NET Runtime if not the .NET SDK, doesn't it? The docs [2] suggest running "dotnet --list-runtimes" to "see which versions of the .NET runtime are currently installed", so it sounds like the Runtime also includes the dotnet command. Does running the recommended "dotnet --list-runtimes" command send telemetry, like most of the commands? Or are you saying that the Runtime, unlike the SDK, doesn't include telemetry at all?

[1] https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

[2] https://docs.microsoft.com/en-us/dotnet/core/install/how-to-...

[sandyarmstrong]

> However, presumably PowerShell requires at least the .NET Runtime if not the .NET SDK, doesn't it?

Nope, these days .NET programs (like PowerShell) bundle the runtime. But even if they did a lighter distribution that depended on the runtime already being installed, there would be no .NET telemetry sent.

> Does running the recommended "dotnet --list-runtimes" command send telemetry, like most of the commands?

This is still an SDK command. I don't personally know if this one sends any telemetry.

> Or are you saying that the Runtime, unlike the SDK, doesn't include telemetry at all?

The runtime does not send telemetry.

[ptx]

So the "dotnet" command is only in the SDK, not in the separately downloadable Runtime? Does the Runtime have some other command to launch an executable?

Edit: Actually, the ".NET Runtime 6.0.4" [1] (not the SDK) definitely has a "dotnet" command included. Presumably with the telemetry?

[1] https://dotnet.microsoft.com/en-us/download/dotnet/6.0

[sandyarmstrong]

When I say "the runtime", I'm referring to everything that would be bundled into a published .NET program. The base class libraries, the bootstrapper, etc. There is no telemetry here.

Yes, if you download a .NET Runtime distribution, it will include the `dotnet` command from the SDK so that basic commands like `dotnet --list-runtimes` and `dotnet --list-sdks` are available. These commands may send telemetry. But as you probably saw on https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry , using `dotnet path/to/program.dll` to run an unbundled .NET program will never send telemetry.

[brushfoot]

To me a telemetry opt-out is a small price to pay for what PowerShell brings to the table, but to each their own.

> There might be other components, now or in the future, that also send data to Microsoft

Of course. Do your due diligence on whatever you install. No tool should be exempt from that.

[mschuster91]

> Do your due diligence on whatever you install. No tool should be exempt from that.

That's a ridiculous take. 99% of users don't understand what all that technobabble in a typical EULA means, they will just go for the option they are nudged to (which is why first the courts and now enforcement agencies are stepping up their game against that practice [1]).

The way that the GDPR expects stuff to be handled is by getting explicit user consent, the consent must be a reasonably free choice (i.e. deals like "give me your personal data and the app is free, otherwise pay" are banned), and there must not be any exchange of GDPR-protected data without that consent unless technically required to perform the service the user demands. Clearly, a telemetry opt-out is completely against the spirit of the GDPR and I seriously hope for Microsoft to get flattened by the courts for the bullshit they have been pulling for way too long now.

What I would actually expect of Microsoft is to follow the Apple way: have one single central place, ideally at setup and later in the System Preferences, where tracking, analytics and other optional crap can be disabled system-wide.

[1] https://www.hiddemann.de/allgemein/lg-rostock-bejaht-unterla...

[brushfoot]

> That's a ridiculous take

Then it befits a ridiculous state of affairs. It would be great to have the standards you suggest, and it's a shame that we don't. But that doesn't change the fact that we don't, and because we don't, we need to do due diligence on the tools we install.

[jodrellblank]

The GDPR applies to personal data. PowerShell telemetry isn't personal data, so it's not covered by the GDPR. What is reported is documented here:

https://docs.microsoft.com/en-us/powershell/module/microsoft...

and is "anonymized information about the host running PowerShell, and information about how PowerShell is used". It sucks that it has telemetry, but anonymised information about whether a computer ran 10 .exe or 10 cmdlets pales into insignificance against Windows and Edge and OneDrive slurping up names, addresses, files, moving logins to Microsoft accounts, sending browser history to Microsoft, checking downloads with Microsoft, keeping a history of all programs run in Windows for timeline and trying to send that to Microsoft to sync it between devices, moving OneNote to the cloud, having the start menu search be a Bing web search, defaulting to Cortana being a cloud based voice search, sending pen and ink data to Microsoft, and etc. etc.

[mschuster91]

Even the fact that a particular piece of software is used by a specific IP address is enough PII that it's covered under GDPR by most viewpoints. The fact that Microsoft is collecting even more data doesn't excuse telemetry in PowerShell at all.

I would simply wish for no telemetry to happen at all without user consent. If Microsoft wants information about how people use their software or how stable it is and not enough people opt in, they should fucking pay people money for market research and QA.

[jodrellblank]

> "Even the fact that a particular piece of software is used by a specific IP address is enough PII that it's covered under GDPR by most viewpoints."

I draw your attention to the link I posted, and the purple background call out box with the exclamation mark icon and the heading "Note" which says: "Application Insights uses the hosts IP address to determine the geographic location. The IP address is never included in the telemetry data or stored in the database."

> "I would simply wish for no telemetry to happen at all without user consent."

I would, too. So did someone on Github: https://github.com/PowerShell/PowerShell/issues/15722 "Change telemetry from opt-out to opt-in" where Microsoft said "we felt that by making telemetry opt-in it would bias and limit our telemetry in a way that would make less useful to our users."

[mschuster91]

> The IP address is never included in the telemetry data or stored in the database.

It nevertheless is transferred to the origin server (otherwise, how would TCP work), and that is enough for it to be considered under GDPR!

> we felt that by making telemetry opt-in it would bias and limit our telemetry in a way that would make less useful to our users

Well, that still doesn't override the GDPR. The GDPR is law, precisely in the spirit to prevent un-consented tracking!

[ElectricalUnion]

> What I would actually expect of Microsoft is to follow the Apple way: have one single central place, ideally at setup and later in the System Preferences, where tracking, analytics and other optional crap can be disabled system-wide.

This is still GDPR non-compliant, you should have a central place to _opt-in_ tracking, analytics and other optional crap if you so desire.

[mschuster91]

So what? You can opt-in to tracking in the macOS System Preferences, pane "security and data protection", tab "Privacy" at any time you wish should you not have done so during the macOS onboarding process.

In Debian, you can opt-in at setup time or any later time with a simple "dpkg-reconfigure popularity-contest" (even though that one isn't fully GDPR-compliant as you can't easily read what exactly is being done from the same screen).

[ElectricalUnion]

> So what? You can opt-in to tracking in the macOS System Preferences, pane "security and data protection", tab "Privacy" at any time you wish should you not have done so during the macOS onboarding process.

You cannot opt-in. You can go to `System Preferences > Security & Privacy > Analytics & Improvements` and opt-out, but the default is not opt-in.