Skip to content
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

[Package Issue]: Microsoft.PowerShell GDPR consent problem: telemetry is forcefully enabled on either install or upgrade (even if it was already disabled) #149014

Closed
2 tasks done
R-Adrian opened this issue Apr 13, 2024 · 7 comments
Labels
Area-External Installer-Issue Issue with the package's installer. Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@R-Adrian
Copy link

R-Adrian commented Apr 13, 2024

Please confirm these before moving forward

  • I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
  • I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Installation issue.

Brief description of your issue

Microsoft.PowerShell 7 (currently at v7.4.2) forcefully enables telemetry for either initial installation via winget or for updates.

  • when a previous version of PowerShell is installed with telemetry disabled (the telemetry opt-out checkbox selected manually in the MSI installer), upgrading with winget will forcefully enable telemety because the MSI installer does not preserve user preference across updates.
  • when installing PowerShell 7 via winget there is no prompt about telemetry optout and it is set to default (i.e. no optout, telemetry is enabled) - this is a problem in Europe because the law here says that consent should be expressly given for such telemetry tracking

Steps to reproduce

related PowerShell issue: PowerShell/PowerShell#21467

  • if an existing version of PowerShell 7 is installed then uninstall it from control panel.
  • make sure there is no C:\Program Files\PowerShell\7 folder left behind
  • download and install the immediately previous version
    (e.g. 7.4.1 in our case here https://github.com/PowerShell/PowerShell/releases/download/v7.4.1/PowerShell-7.4.1-win-x64.msi )
  • install that version. When installing make sure to enable the checkbox for opt out, to disable telemetry.
  • start pwsh, check the output of the $env:POWERSHELL_TELEMETRY_OPTOUT environment variable
    (it shows 1 in my case)
  • make sure pwsh 7 is not running, start an elevated cmd.exe command prompt, run winget upgrade Microsoft.PowerShell - and update pwsh to version 7.4.2 ( https://github.com/PowerShell/PowerShell/releases/download/v7.4.2/PowerShell-7.4.2-win-x64.msi )
  • after the upgrade is done start pwsh and check the output of the $env:POWERSHELL_TELEMETRY_OPTOUT environment variable again - after the winget silent/unattended update it shows no optout (i.e. the telemetry is now forcefully enabled again)

Actual behavior

  • PowerShell 7 telemetry is forcefully enabled on upgrade, even if it was previously disabled (with the optout checkbox enabled)
  • when installing from scratch with winget install Microsoft.PowerShell, PowerShell 7 telemetry is forcefully enabled (default state) without any explicit consent requested or given about it.

Expected behavior

  • when upgrading - the telemetry optout preference should be preserved, not wiped as it does now.

  • when installing - in Europe (GDPR) - the telemetry should probably default to off (passed via the DISABLE_TELEMETRY MSI installer flag) as required by Article 6 of the GDPR.

Environment

(environment not relevant - this is an issue with the MSI installer and the parameters passed by the winget package manager to it)

Screenshots and Logs

PowerShell telemetry reference:
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_telemetry?view=powershell-7.4

PowerShell 7.4.1 manual installation of the MSI file, with telemetry disabled:
PowerShell 7.4.1 installation with telemetry disabled

checking before upgrade...
pwsh_741_before_upgrade

and running winget upgrade Microsoft.PowerShell (using the old Windows PowerShell instead of cmd.exe as a console window)

pwsh_742_winget_upgrade_

... PowerShell 7 telemetry optout is now disabled and the variable is not defined anymore - this means that telemetry was forcefully enabled during the upgrade.

pwsh_742_after_upgrade

@R-Adrian R-Adrian added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Apr 13, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage This work item needs to be triaged by a member of the core team. label Apr 13, 2024
@R-Adrian R-Adrian changed the title [Package Issue]: Microsoft.PowerShell GDPR consent problem: telemetry is forcefully enabled on either install or update (even if it was already disabled) [Package Issue]: Microsoft.PowerShell GDPR consent problem: telemetry is forcefully enabled on either install or upgrade (even if it was already disabled) Apr 13, 2024
@Trenly
Copy link
Contributor

Trenly commented Apr 13, 2024

@cinnamon-msft / @denelon - This seems like it might be more an issue with the PowerShell installer than with WinGet?

@denelon - Do Agreements need to be added to the manifest for GDPR?

@microsoft-github-policy-service microsoft-github-policy-service bot removed the Needs-Triage This work item needs to be triaged by a member of the core team. label Apr 13, 2024
@R-Adrian
Copy link
Author

R-Adrian commented Apr 14, 2024

This seems like it might be more an issue with the PowerShell installer than with WinGet?

The PowerShell 7 MSI installer supports parameters equivalent to those checkboxes during the manual installation... but the installer does not seem to preserve the install settings from the previous version when upgrading, so IMHO it falls to WinGet to pass the appropriate parameters to the installer, especially since Microsoft recommends the use of WinGet to handle both the initial installation or the upgrades of PowerShell 7.
Handling the initial installation means WinGet has to handle obtaining the telemetry tracking consent too, but such consent must not be a mandatory condition to the installation of the application.

https://learn.microsoft.com/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.4

quotes from that page:
Install PowerShell using Winget (recommended)
Winget, the Windows Package Manager, is a command-line tool enables users to discover, install, upgrade, remove, and configure applications on Windows client computers. This tool is the client interface to the Windows Package Manager service. The winget command-line tool is bundled with Windows 11 and modern versions of Windows 10 by default as the App Installer.
[...snip...]

Install the MSI package from the command line
MSI packages can be installed from the command line allowing administrators to deploy packages without user interaction. The MSI package includes the following properties to control the installation options:

  • ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL - This property controls the option for adding the Open PowerShell item to the context menu in Windows Explorer.
  • ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL - This property controls the option for adding the Run with PowerShell item to the context menu in Windows Explorer.
  • ENABLE_PSREMOTING - This property controls the option for enabling PowerShell remoting during installation.
  • REGISTER_MANIFEST - This property controls the option for registering the Windows Event Logging manifest.
  • ADD_PATH - This property controls the option for adding PowerShell to the Windows PATH environment variable.
  • DISABLE_TELEMETRY - This property controls the option for disabling PowerShell's telemetry by setting the POWERSHELL_TELEMETRY_OPTOUT environment variable.
  • INSTALLFOLDER - This property controls the installation directory. The default is $env:ProgramFiles\PowerShell. This is the location where the installer creates the versioned subfolder. You can't change the name of the versioned subfolder. For current releases, the versioned subfolder is 7

/quotes

@Trenly
Copy link
Contributor

Trenly commented Apr 14, 2024

This seems like it might be more an issue with the PowerShell installer than with WinGet?

The PowerShell 7 MSI installer supports parameters equivalent to those checkboxes during the manual installation... but the installer does not seem to preserve the install settings from the previous version when upgrading, so IMHO it falls to WinGet to pass the appropriate parameters to the installer, especially since Microsoft recommends the use of WinGet to handle both the initial installation or the upgrades of PowerShell 7. Handling the initial installation means WinGet has to handle obtaining the telemetry tracking consent too, but such consent must not be a mandatory condition to the installation of the application.

https://learn.microsoft.com/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.4

quotes from that page: Install PowerShell using Winget (recommended) Winget, the Windows Package Manager, is a command-line tool enables users to discover, install, upgrade, remove, and configure applications on Windows client computers. This tool is the client interface to the Windows Package Manager service. The winget command-line tool is bundled with Windows 11 and modern versions of Windows 10 by default as the App Installer. [...snip...]

Install the MSI package from the command line MSI packages can be installed from the command line allowing administrators to deploy packages without user interaction. The MSI package includes the following properties to control the installation options:

  • ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL - This property controls the option for adding the Open PowerShell item to the context menu in Windows Explorer.
  • ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL - This property controls the option for adding the Run with PowerShell item to the context menu in Windows Explorer.
  • ENABLE_PSREMOTING - This property controls the option for enabling PowerShell remoting during installation.
  • REGISTER_MANIFEST - This property controls the option for registering the Windows Event Logging manifest.
  • ADD_PATH - This property controls the option for adding PowerShell to the Windows PATH environment variable.
  • DISABLE_TELEMETRY - This property controls the option for disabling PowerShell's telemetry by setting the POWERSHELL_TELEMETRY_OPTOUT environment variable.
  • INSTALLFOLDER - This property controls the installation directory. The default is $env:ProgramFiles\PowerShell. This is the location where the installer creates the versioned subfolder. You can't change the name of the versioned subfolder. For current releases, the versioned subfolder is 7

/quotes

Fundamentally all WinGet does is download and run the installer. There is no way for WinGet to know what settings a user previously installed with, especially if PowerShell was installed oustide of WinGet.

If you were to download the MSI and run it from the commandline with the /qn switch you would see the same behavior where the telemetry option is reset on a new instal or upgrade.

Yes, it is true that WinGet can pass some pre-defined switches to installers, but they are generally applied to every install. Either way, WinGet wouldn’t be able to detect the application level setting and change its behavior based on that. Therefore, it really needs to be the PowerShell installer that (when running unattended) checks for previous install settings and respects them

@StevenBucher98
Copy link

So I was working on reproduction and reproduced it for winget, had same MSI and did winget install via cmd.exe but in same cmd.exe session launched pwsh.exe and was on 7.4.2 and $env:POWERSHELL_TELEMETRY_OPTOUT was 1 in that session but when I closed that and reopened PS7 it was no longer set.

Still investigating

@anamnavi
Copy link
Contributor

anamnavi commented Apr 15, 2024

@R-Adrian thanks for creating this issue. The following PR may address the issue: PowerShell/PowerShell#20420

@microsoft-github-policy-service microsoft-github-policy-service bot added Installer-Issue Issue with the package's installer. Area-External labels Apr 15, 2024
@StevenBucher98
Copy link

A work around is to do winget upgrade Microsoft.PowerShell --interactive to open up the MSI installer GUI again to reset the settings.

Copy link
Contributor

Hello @R-Adrian,

This issue has been identified as requiring a fix from a third party or external repository. Since there has been no recent activity on this issue, it will be automatically closed.

Template: msftbot/noRecentActivity/areaExternal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-External Installer-Issue Issue with the package's installer. Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

4 participants