Updating Chrome installations in user-profile

[s016aq]

Hi!
I'm in the process of enabling updates in user-context and during testing I ran in to a problem.
I'm using a whitelist and one of the applications in the list is google.chrome (I know Chrome updates it self, but this is just to make updates faster)
When I enabled updates in user-context and WAU finds an old user-installed version of Chrome it tries to update it. But the update is machine-wide. Meaning the user will get an UAC-prompt. I realize this has nothing to do with WAU, but is rather a Chrome-manifest-problem. Either it should not be detected or it should update in the same way as the original install.
But do anyone has a smart solution for things like this? Right now, the only way around it is to remove Chrome from our whitelist (or don't use user-update).

[AndrewDemski-ad-gmail-com]

You are right, that it is caused by google chrome installation method.
here you may see that in both contexts - user and machine - it uses the same installer(s) and detection method(s).

Google decided to use the same MSI to be installed either in user or machine context.
It is the installer itself, when seeing machine-installed chrome, decides to present UAC prompt.

Removal of user-side applications and blocking user initiated installations is the proper way.
If you would like to speed up process of propagating google chrome updates, then I recommend enforcing relaunch policy described here That is a god-level smacking hammer which speeds up the completion of chrome update process for those who ignore official communication. In longer run it will save you a lot of problems.

Also, pardon my honesty, but if WAU is triggered on a daily basis and chrome has its own auto-update task(s) running, then what is the benefit of checking for update more often that once a day?

[s016aq]

We are already using the relaunch policys. I agree it's a bit overkill to include Chrome in WAU, so I guess I remove it from the whitelist for now. But this could be a problem to other apps also. And very hard to to predict when it will be an issue. Other applications also installs both in user and machine context (zoom & firefox comes to mind). Those are not a problem, but as I said, hard to test and predict. We don't want UAC-prompts on hundreds of computers. One solution could be to use different whitlists for user and machine.

[AndrewDemski-ad-gmail-com]

If PackageIdentifier contains only <manufacturer>.<application>, then winget will be oblivious to some important context.

There is a simple explanation to FireFox ability to maintain stability of own application ecosystem during upgrades.
They are using manifest schema 1.5 to he fullest. I love what they had done!

Take a look at that beauty: https://github.com/microsoft/winget-pkgs/blob/master/manifests/m/Mozilla/Firefox/121.0.1/Mozilla.Firefox.installer.yaml
We have separate identifiers for each channel:

• PackageIdentifier: Mozilla.Firefox.DeveloperEdition
• PackageIdentifier: Mozilla.Firefox
• PackageIdentifier: Mozilla.Firefox.ESR

Zoom made a perfect order in their manifests as well https://github.com/microsoft/winget-pkgs/blob/master/manifests/z/Zoom/Zoom/5.17.5.31030/Zoom.Zoom.installer.yaml

Some vendors realized that by using relaxed requirement in creation of PackageIdentifier/id (schema 1.4) and not using Installation scope they introduce unnecessary chaos.
Even M$ is aware of that fact, they did split the MSTeams into separate channels that way.

On the opposite end of the quality spectrum we have 7zip still using manifest schema 1.4 and a complete mess during upgrades (#539).

Also There are external factors which are out of control of winget (and as an extension WAU). I'd call them root causes of unnecessary blind spots.

I mentioned those in #539 (#539 (comment))
(TL;DR: garbage in > garbage out)