undergroundwires / privacy.sexy

Open-source tool to enforce privacy & security best-practices on Windows, macOS and Linux, because privacy is sexy
https://privacy.sexy
GNU Affero General Public License v3.0
4.05k stars 172 forks source link

[BUG]: Edge Browser uninstall process no longer works #236

Closed TheAndr0id closed 1 year ago

TheAndr0id commented 1 year ago

Description

Microsoft has added extra sillyness to keep their Edge browser installed. Calling the uninstall process from the privacy.sexy application no longer works. Trying to remove Edge with the AppxPackage functions also fails.

OS

Windows 10 x64 22H2

Reproduction steps

Go under "Remove Bloatware, select Uninstall Edge" Run the generated code. Edge is still installed.

Scripts

privacy-script.txt

Additional information

Don't worry, I got you. This credit goes to the Atlas OS team who have discovered this devious work around for Microsoft's bullsh*ttery. They actually give credit in their script to another developer:

Major credit to ave9858: https://gist.github.com/ave9858/c3451d9f452389ac7607c99d45edecc6

The Powershell script used by the Atlas-OS team may be found here:

https://github.com/Atlas-OS/Atlas/blob/main/src/playbook/Executables/AtlasDesktop/1.%20Software/Remove%20Edge.ps1

The trick in all this? They are marking Edge and it's other packages as END OF LIFE. This removes the "NonRemovable" tag and then Remove-AppPackage can do it's job. (There's also another entry in the registry which allows Edge uninstall, but I'm not sure that's what's doing the work - please see the above script ~line 50)

Adding keys for the PackageFullName of the package under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\EndOfLife\SID

where SID is determined with the following Powershell code: (I'm not interested in learning what this is, it just works)

$user = $env:USERNAME
$SID = (New-Object System.Security.Principal.NTAccount($user)).Translate([Security.Principal.SecurityIdentifier]).Value

Then after removing the package this key can be deleted. This might also be a good way to prevent Edge from reinstalling itself in the future. The above process worked for the base Edge package as well as the Microsoft.MicrosoftEdgeDevToolsClient packages.

The "Edge Update" package that doesn't seem to have an uninstall script (go figure) and there isn't an Appx package installed either. I have not let Edge update itself, so this might be the reason. In my case I deleted the directory and related registry entries to clear up the application manager listing.

I've submitted this issue so privacy.sexy can update their scripts.

In any case, bravo people. Bra-vo!

kajoken commented 1 year ago

I just used the Atlas-OS Script and for me the "Edge Update" package was also removed. Maybe it was fixed already.

undergroundwires commented 1 year ago

@TheAndr0id , thank you for nice issue and all the explanation. It makes it easy for us to fix the bug. Would you like to send a PR? I will merge if there's a PR and can help it if there's any issue. You'd take a look at windows.yaml to add missing stuff.

I can fix this eventually but have some other priorities for oncoming patches to fix some stability/maintainability issues, so no promises soon. But I would merge a PR or if someone sends a clean script with necessary information.

TheAndr0id commented 1 year ago

I'm sorry, I'm not a developer but a Unix sysadmin. I'm just trying to get Windows 10 installed without all the crapware Microsoft loaded it with so I can continue using Steam. Frankly the less Windows I know the happier I am.

I also don't have a test/VM environment to do any test builds in and I've already put more stress on my new shiny SSD than I wanted to with this install...

I've looked at other "cleaner" tools and I like your vision of the web based toolkit applying changes instead of fundamentally changing the OS like the Atlas-OS project is doing.

Unless you have problems with this, I'll continue to submit tickets as I find issues and what solutions I've found. Fix/test/implement as you see fit.

undergroundwires commented 1 year ago

Removing Chromium Edge

I tested removing new Edge (Chromium) on w11 and can reproduce this. I see two issues:

  1. Script fails when there are multiple versions of Edge
  2. Microsoft as uninstallable 1 and their uninstaller rejects to uninstall.

Here's a fixed script that addresses both issues and that removes Chromium Edge successfully with better output messages:

reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdateDev" /v "AllowUninstall" /t REG_DWORD /d "1" /f
PowerShell -ExecutionPolicy Unrestricted -Command "$installer = (Get-ChildItem "^""$($env:ProgramFiles)*\Microsoft\Edge\Application\*\Installer\setup.exe"^""); if (!$installer) {; Write-Host 'Installer not found. Microsoft Edge may already be uninstalled.'; } else {; $installer | ForEach-Object {; $uninstallerPath = $_.FullName; $installerArguments = @("^""--uninstall"^"", "^""--system-level"^"", "^""--verbose-logging"^"", "^""--force-uninstall"^""); Write-Output "^""Uninstalling through uninstaller: $uninstallerPath"^""; $process = Start-Process -FilePath "^""$uninstallerPath"^"" -ArgumentList $installerArguments -Wait -PassThru; if ($process.ExitCode -eq 0 -or $process.ExitCode -eq 19) {; Write-Host "^""Successfully uninstalled Edge."^""; } else {; Write-Error "^""Failed to uninstall, uninstaller failed with exit code $($process.ExitCode)."^""; }; }; }"

The script above should successfully remove Edge chromium with minimal changes.

I also added revert code that will reinstall Edge:

reg delete "HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdateDev" /v "AllowUninstall" /f 2>nul
PowerShell -ExecutionPolicy Unrestricted -Command "$edgeExePath = Get-ChildItem -Path "^""$($env:ProgramFiles)*\Microsoft\Edge\Application"^"" -Filter 'msedge.exe' -Recurse; if ($edgeExePath) {; Write-Host 'Microsoft Edge is already installed. Skipping reinstallation.'; Exit 0; }; Write-Host 'Downloading Microsoft Edge...'; $edgeInstallerUrl = 'https://c2rsetup.officeapps.live.com/c2r/downloadEdge.aspx?platform=Default&Channel=Stable&language=en'; $downloadPath = "^""$($env:TEMP)\MicrosoftEdgeSetup.exe"^""; Invoke-WebRequest -Uri "^""$edgeInstallerUrl"^"" -OutFile "^""$downloadPath"^""; $installerArguments = @('/install', '/silent'); Write-Host 'Installing Microsoft Edge...'; $process = Start-Process -FilePath "^""$downloadPath"^"" -ArgumentList "^""$installerArguments"^"" -Wait -PassThru; Remove-Item -Path $downloadPath -Force; if ($process.ExitCode -eq 0) {; Write-Host 'Successfully reinstalled Microsoft Edge.'; } else {; Write-Error "^""Failed to reinstall Microsoft Edge. Installer failed with exit code $($process.ExitCode)."^""; }"

Let me know if it worked for you or if you still see any other issues with reinstalling and revert, then we can publish a patch for this.

I will look at legacy Edge (AppxPackage) later. And please keep posting, you're a valuable member of our community and your contributions are appreciated.

undergroundwires commented 1 year ago

Removing Legacy Edge

I cannot reproduce this. It works fine as of now. privacy.sexy soft deletes system apps including Edge by relocating them and making them inaccessible to the system. It ensures that the functionality is not there, but gives a robust way to revert the changes with the existing state of the applications just like before.

There are some other ways like iterating each SID and setting these system apps as end-of-life, deprovisioned etc. as in your example. Or calling dism to set them as removable etc. I've seen these when I initially implemented the system app removal but found those much more intrusive. I think the way privacy.sexy handles is more unique and I think is more secure and easily reversible, still ensuring that the apps are no longer available.

Changing this logic would change how we disable/remove all other system apps. And if you think that this still is relevant and we should do deeper delete on these, I'm open to here arguments in a separate issue because it's not really about Edge.

Here is how privacy.sexy uninstalls system apps.

TheAndr0id commented 1 year ago

Sorry for not commenting earlier, life things have been in the way. This ended up being a longer reply than intended...

TL;DR: I don't agree, but it's your sandbox. 😄

This was one of the first things I approached when trying to roll out Windows 10. Edge/Chrome is a browser that I will never use (I'd go back to using lynx day to day before that), so it was my first target to remove. It was early in my process and I didn't know there were two different versions of Edge.

Initially I didn't let the Edge updater run as it didn't make sense since I was removing the product. At the default position of an 22H2 Windows 10 install, "Legacy Edge" is in place but immediately prompts for the upgrade. Edge Chromium was installed as part of the system updates that I did thinking that was the correct first step.

Throughout my process I've been trying to remove/disable system "stupidity" using standard methods. Uninstalling apps, setting registry keys, turning off services. Things that can easily be tracked and reproduced when the system reinstall inevitably happens. I've been avoiding solutions of changing binary names, hard removing files and directories and just well, whacking things with a "Big F'ing Hammer".

I'm not going to try to dictate your development or how your process works. I just found a "correct" process that worked within the Microsoft tools (even if it's using their own methods to work around them). We all know their "claim" that Edge is critical for Windows is utter crap (I've been running for weeks now with no Edge installed with NO consequences), and this "NonRemovable" tag is, well, I'm not going to say what I think of it.

My personal opinion (and it's just that) is renaming/removing binaries without removing them properly from the system is going to come back to haunt you. Microsoft is getting away with this nonsense because law makers are busy dealing with Trump/Covid/Ukraine/"More Important" things instead of a monopoly that needs to be investigated and charged for violating privacy laws. I'll step down from this soapbox now....

The bottom line for me? I have a script that removes Edge (both versions) using Microsoft's own tools and their own methods. I'm going to continue using that process. I put in the ticket because after trying privacy.sexy Edge still showed in the Installed Apps list and that wasn't going to cut it for me. I found this method that worked, and I passed it on.

I think the way privacy.sexy handles is more unique and I think is more secure and easily reversible, still ensuring that the apps are no longer available.

I think you might want to review that as well. I tried the "Windows Defender" removal script and it caused all sorts of issues (settings sections crashing, other network tools failing to start, etc.). Using the revert script seemed to cause a different set of problems. Before you ask, I don't have details since I believe that led to re-install 4? 5? It's all a bit of a blur at this point and I'm very willing to accept that the problem with that process was between the keyboard and chair. (Thus why I didn't open an Issue - I decided that just disabling the service was the best way forward)

Once again, just my opinion, but I think you may very well end up with multiple ".old" binaries laying around on the system when Microsoft decides that updates are going to be "new version installs".

TheAndr0id commented 1 year ago

I'm going to add this comment in case someone googles upon this looking for an answer. (and if the maintainer changes his mind - 😄 )

In order for this to work, you need to know your user SID. This can be gotten with the following CMD script: (It's ugly, but it works)

for /F "tokens=2 delims=," %%i in ('whoami /user /fo csv /nh') do set USERSID=%%~i

To determine if a package needs this, check for the NonRemovable tag. For example, look at this output of Get-AppxPackage and note the NonRemovable field:

Name                   : Microsoft.Windows.CapturePicker
Publisher              : CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture           : Neutral
ResourceId             :
Version                : 10.0.19041.1023
PackageFullName        : Microsoft.Windows.CapturePicker_10.0.19041.1023_neutral__cw5n1h2txyewy
InstallLocation        : C:\Windows\SystemApps\Microsoft.Windows.CapturePicker_cw5n1h2txyewy
IsFramework            : False
PackageFamilyName      : Microsoft.Windows.CapturePicker_cw5n1h2txyewy
PublisherId            : cw5n1h2txyewy
PackageUserInformation : {S-1-5-21-1414533865-2100132221-529572658-1001 [Bill]: Installed}
IsResourcePackage      : False
IsBundle               : False
IsDevelopmentMode      : False
NonRemovable           : True
IsPartiallyStaged      : False
SignatureKind          : System
Status                 : Ok

Now, as long as USERSID environment variable is set, the following line of powershell will add the package's registry key to the EndOfLife registry tree, remove the package and then delete the registry entry.

PowerShell -ExecutionPolicy Unrestricted -Command "$package = (Get-AppxPackage 'Microsoft.Windows.CapturePicker').PackageFullName ;  if (!$package) {; Write-Host 'Not installed'; exit 0; }; New-Item -Path \"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\EndOfLife\%USERSID%\$package\" -Force | Out-Null; Remove-AppxPackage $package ; Remove-Item -Path \"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\EndOfLife\%USERSID%\$package\" -Recurse -Force | Out-Null;"
undergroundwires commented 1 year ago

Hi @TheAndr0id,

I understand your concerns and am open to the changes you suggest. However, as the primary developer with other responsibilities, I have to prioritize tasks. While I've received ad offers, I declined them to maintain a good user experience. Donations haven't covered costs, and I'm leaning on community support for continued development. Any help would be appreciated.

I want to talk about some concerns and get feedback:

Restoring user state (app data)

Using powershell (batch code becomes too complicated):

  1. Locate application folder, ZIP it, save it as .OLD.
  2. Modify package metadata to be removable.
  3. Uninstall the package.

Once reverted,

  1. Install the package and fix the metadata.
  2. Unzip .OLD package into installation and delete it.

Some concerns:

In the end, should we keep this back-up logic or not have it at all?

Reverting packages (reinstalling them)

Is it possible to re-install these packages? How do we do that?

Current code to reinstall non-system packages:

  $package = Get-AppxPackage -AllUsers '{{ $packageName }}'
  if (!$package) {
      Write-Error "Cannot reinstall '{{ $packageName }}'" -ErrorAction Stop
  }
  $manifest = $package.InstallLocation + '\AppxManifest.xml'
  Add-AppxPackage -DisableDevelopmentMode -Register "$manifest"

Resiliency against Windows updates

Soft deleting system apps are resilient against Windows updates. Because the package states stays as installed as you realized, Windows updates do not try to reinstall the packages.

Would your suggestion work against Windows updates? Or will each update run integrity checks install these packages back? How can we avoid this?

Collection of all documentation we can find

Do we have any reputable/official documentation we can find about this? Anything really, from SID to metadata edits, to Windows update behavior etc.

TheAndr0id commented 1 year ago

Hi @TheAndr0id,

I understand your concerns and am open to the changes you suggest. However, as the primary developer with other responsibilities, I have to prioritize tasks. While I've received ad offers, I declined them to maintain a good user experience. Donations haven't covered costs, and I'm leaning on community support for continued development. Any help would be appreciated.

I hope that my comments weren't taken in terms of "you're lazy" or "why don't you do this". That was in no way my intention and I'm sorry if my comments came across that way. This is your project, I'm just here trying to offer support and some help if I can. I like what I see...

I added the previous comment to help others who might come across this issue via Google. Nothing I hate worse than finding my problem with a "solved" tag that isn't complete...

I guess I get a little twitchy when I see .old files. I use .old files for quick one time hacks to test/resolve issues before I find the complete long term solution. I delete .old files because they're well, old. I also found that some of the Microsoft system/configuration tools/apps did strange and bad things when binaries they wanted were missing.

I've been trying my best to follow your standards where and when I can. I understand why the "one liner" scripts are being used, even though they are damn fugly to read... 😃 I also understand that any open source project can always use more bodies.

In my case I just want this nightmare to end. Windows 10/11 is in my opinion junkware that I'll be glad to be done with. I have two machines to update, one which won't be done for a few months, one which needed to be done before Steam pulled the plug. I was happy with Windows 7. Everything worked in Windows 7. I want Windows 7 back.

It's irresponsible to say I'll help with your project and then in a month (hopefully less) bail never to be seen again. That doesn't help you at all.

That being said I have no issues sharing my secret finds in the dread cave of Microsoft. I'm getting value, I have no issues "sharing the love"...

I want to talk about some concerns and get feedback:

Restoring user state (app data)

...

Some concerns:

* Is it important to restore user state?

* Is it security vulnerability to ZIP and save user state? This may include information that can be studied to understand user behavior.

In the end, should we keep this back-up logic or not have it at all?

I'd say leave that to the user. I see this tool as something you do to a machine at install time (or track your changes to apply at the next install time). For example, if you don't want Microsoft Store on your machine, then 1) you shouldn't have used it to begin with and 2) If you have apps/data from that service you need, then well you can't remove it.

We're not talking about things like tax software that you use for a week a year, save the data files and uninstall the software. Much of this bloatware is garbage that should never have been rolled out (look at what they did to innocent little Solitare!).

My thought is if data is stored under the User's directory, leave it there. Let the user handle their own data and then you can't be blamed for "deleting" stuff. If the data is removed as part of the package removal, then let it do it's thing. If it leaves breadcrumbs (ini files, bookmarks, registry entries) after it's uninstall, that's on Microsoft for not providing a complete uninstall script.

Reverting packages (reinstalling them)

Is it possible to re-install these packages? How do we do that?

Current code to reinstall non-system packages:

From my Googling, that seems to be the same process for system packages as well. I have not tested since I don't want them back... 😄

Resiliency against Windows updates

Soft deleting system apps are resilient against Windows updates. Because the package states stays as installed as you realized, Windows updates do not try to reinstall the packages.

I found this document from Microsoft:

https://learn.microsoft.com/en-us/windows/application-management/remove-provisioned-apps-during-update#create-registry-keys-for-deprovisioned-apps

It states:

When you update a computer running Windows 10, version 1703 or 1709, you might see provisioned apps that you previously removed post-update. This can happen if the computer was offline when you removed the apps. Windows 10, version 1803 has fixed this issue.

and that adding keys under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\

to be a second layer (I guess?). It's not like Microsoft has stopped following their own guidelines before....

I've been also thinking that maybe keeping the packages listed under the EndOfLife tree might be a belt/suspenders/chicken wire/duct tape method to stop Windows Update from possibly putting it back.

Would your suggestion work against Windows updates? Or will each update run integrity checks install these packages back? How can we avoid this?

I can't walk past the opportunity for a Star Trek quote: "It's worked so far, but we're not out yet."

So far it seems to be working. I haven't had Edge return (that being said I am using the DoNotUpdateToEdgeWithChromium registry key as well) or any of the other software I've removed. (Stay away Solitare, stay away!)

I'm also running on a new install (yet again) since I ran into issues with activation keys. (Windows 10 Home keys do NOT work on Windows 10 Home N. Only way to fix? Reinstall of course!)

Collection of all documentation we can find

Do we have any reputable/official documentation we can find about this? Anything really, from SID to metadata edits, to Windows update behavior etc.

This might be a problem. Microsoft doesn't want us doing this. The whole EndOfLife thing is a HUGE work around that seems to behave correctly (at least for now). I did some searching and couldn't find any Microsoft documentation on the EndOfLife registry tree. (Microsoft's search engine keeps turning it into "End of life" and returning ALL documents listing their end of life dates....)

As for the SID, I believe it's kind of a unique user identifier (kind of like UID/GID under Unix). There were LOTS of google hits where people we searching for it and it's easy to find through the "whoami" command. I don't think SID is anything magical to cause concern.

The big issue here is Microsoft. They've got an agenda which is not compatible with their users. They tell lies (Edge is critical for system stability), they steal data(telemetry? No, spyware.), they lock services in place to increase market share (Windows Defender, Edge) and frankly anyone who trusts them haven't been paying attention. Now they aren't alone (Mozilla, Google, Apple, etc.) and we're stuck using their systems until something better happens (we hope).

I don't think it matters what we do, we're breaking their "rules" and we're all a bunch of "hackers". How many other tweaking/streamlining apps have they blacklisted with Defender because they didn't like what the tools were doing?

Personally after Microsoft pulled the whole GWX force install Windows 10 tool in critical security updates thing a few years back, I have ZERO trust for them. I plan on disabling Windows Update once this system build is finished. I'll look at what updates are available every 4-6 months and install as needed. Now that's my choice, and I totally understand that's not a direction this project can take...

undergroundwires commented 1 year ago

Your feedback is invaluable! ❤️

I'd say leave that to the user

I'm on the same page. Your rationale makes sense to me, and this behavior would be consistent with rest of other scripts too.

Reverting packages (reinstalling them)

We need to test this properly.

Deprovisioned + EOF

My primary concern here was Windows updates. Appreciate your deep dive and the suggestion with EOF. Replicating and testing Windows updates is challenging. We can initially categorize it under 'deprovisioned', discard the EOF key, and then wait for community feedback. This way, we adhere to the official docs until proven otherwise.

SID

Exactly! SID appears to be a combination of UID (user) + GID (group ID). Rather than just targeting the current user's SID, we should iterate all SIDs exists in the system and run the logic.

To sum it up, I'll take the responsibility of implementing this and further research any additional documentation. Given the magnitude of these changes, which affect not just the Edge scripts but the removal process of all system apps, it seems like a minor release instead of a patch release would be better suitable. privacy.sexy does not follow semantic versioning but I will still think about this.

Decisions

Other points

This is your project

It started with my personal script collection, but at this stage it's a collaborative effort of privacy enthusiasts. I do not consider this my project but more like a common effort of us privacy enthustiasts which I faciliate/coordinate with more effort. The open-source nature and license allow it to belong to anyone and everyone.

never to be seen again

Your dedication shines through, and it's heartening to know you're sticking around. Let's use this momentum and achieve as much as we can. You've been a top contributor recently, and that doesn't go unnoticed. The impact of our discussions are big, our page sees roughly 6K organic visits daily, with over 100K downloads. These contributions affect and help many.

On the subject of data collection, data harvesting can be justified by free services but if I pay for a product, I want opt-in with consent for everything. Explicit consent should not be enforced by a third-party tool like ours but should be there byy default. Unfortunately, such this is caused by monopolies and the inaction of regulators. I'm pretty sure Linux will gain a lot more traction for desktop users, especially in more "isolated" parts of the world that got scared by sanctions and similar moves which removed trust in the monopolies and shifted focus on Linux.

Windows Updates: There were some bugs, the fix will be released in a few days. Windows Defender: There has been some changes in recent patches. If you still have issues, feel free to create an issue if you find the time so we can fix it. Solitaire: I do not have the context about what happened to it, I guess it has also become a spyware.

Again, thank you for your insights and commitment. It's partnerships like these that drive projects forward.

I created #260 to fix the issue with system app deletion. We can scope this issue to legacy edge removal.

undergroundwires commented 1 year ago

The fix for new Edge is released in 0.12.4 🚀 for legacy Edge, let's track it in #260 (hope it's ok to close this @TheAndr0id).

TheAndr0id commented 11 months ago

Sorry to open up a closed ticket, but I just got the latest update from jackasses (Microsoft) (KB5031356) and not only did they overwrite all of the search settings with their new "security" update (and a newer version of the search bar), they also reinstalled Edge with the update. I did not have the key in the Deprovisioned registry key set, but so much for "Resiliency against Windows updates" policy. I don't think DoNotUpdateToEdgeWithChromium registry value does anything anymore.

I have now disabled Windows Update as per your instructions here (and I'll be keeping an eye on it to make sure it doesn't come back on).

I so hate Microsoft.

undergroundwires commented 11 months ago

"Security update" 😀 Microsoft has been exploiting the word security too much both in enterprise world to oversell, and to individuals to enforce data collection.

I think it's good to create new issues for this so we can track/follow-up their progress separately.

DoNotUpdateToEdgeWithChromium seems to be dead. I found these to block (re)installation of Edge:

Unsure if they work but comes from official documentation.

:: Default
reg add "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "InstallDefault" /t "REG_DWORD" /d "0" /f
:: Stable
reg add "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "Install{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}" /t "REG_DWORD" /d "0" /f
:: Beta
reg add "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "Install{2CD8A007-E189-409D-A2C8-9AF4EF3C72AA}" /t "REG_DWORD" /d "0" /f
:: Canary
reg add "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "Install{65C35B14-6C1D-4122-AC46-7148CC9D6497}" /t "REG_DWORD" /d "0" /f
:: Dev
reg add "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v "Install{0D50BFEC-CD6A-4F9A-964C-C7416E3ACB10}" /t "REG_DWORD" /d "0" /f