Closed Bug 1876302 Opened 1 year ago Closed 1 year ago

Application Autoupdate (AppAutoUpdate / app.update.auto) and Background updater (BackgroundAppUpdate / app.update.background.enabled) GPO Enterprise policies don't create the Firefox Background Update job in Windows Task Scheduler

Categories

(Firefox :: Enterprise Policies, defect)

Product:
Firefox
Component:
Enterprise Policies
Version:
Firefox 122
Platform:
x86_64
Windows
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: alexeyc2003, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(2 files)

Firefox-Bug-1876302.txt
10.32 KB, text/plain
Details
Firefox-Bug-1876302-debug.txt
25.38 KB, text/plain
Details

It seems the Firefox Updates Settings GUI changes is the only thing that triggers creation of the Firefox Background Update task in the Windows Task Scheduler (Win 11 23H2).

If the Firefox Background Update task does not already exist, enabling the following GPO Enterprise policies (Computer) doesn't create it:

  • Application Autoupdate (AppAutoUpdate / app.update.auto)
  • Background updater (BackgroundAppUpdate / app.update.background.enabled) GPO Enterprise policies

Application Autoupdate policy removes the corresponding Firefox Updates GUI Settings alltogether, so it becomes impossible to create the Firefox Background Update task.

The only way to create the Firefox Background Update task in the Windows Task Scheduler becomes:

  1. Remove Firefox GPO Application Autoupdate/Background updater policies
  2. Restart Firefox
  3. Update/toggle the Firefox Updates Settings GUI
  4. Run/Refresh Task Scheduler and verify that the Firefox Background Update task has been created
  5. Reapply Firefox GPO Application Autoupdate/Background updater policies
  6. Restart Firefox

We've had quite a few people request the ability to create the background task independent of using Firefox.

We should create a simple way to do this or document how to do it.

The BackgroundAppUpdate policy was added to disable background update, not enable it.

(In reply to Alexey Chernyak from comment #0)

It seems the Firefox Updates Settings GUI changes is the only thing that triggers creation of the Firefox Background Update task in the Windows Task Scheduler (Win 11 23H2).

That doesn't sound like the expected behavior. Could you please enable app.update.log in about:config, open the browser console (Control+Shift+J), set the filter to AUS:, reproduce this bug, and attach the resulting console messages to this bug so that I can see what's going on?

(In reply to Mike Kaply [:mkaply] from comment #1)

We've had quite a few people request the ability to create the background task independent of using Firefox.

I don't really have any idea how this is meant to work. How can we do, well, anything by only setting a policy? We could certainly create, like, a background task or something that would register the Background Update Task, but is there a way to invoke it by just setting a policy and never actually running Firefox?

Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

Flags: needinfo?(mozilla)
Flags: needinfo?(alexeyc2003)

I don't really have any idea how this is meant to work. How can we do, well, anything by only setting a policy? We could certainly create, like, a background task or something that would register the Background Update Task, but is there a way to invoke it by just setting a policy and never actually running Firefox?

Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

This wouldn't policy related, it would be some other documentation (or application?) that explained to focus how they can create the background task themselves.

People understand the profile requirement but it seems like there are cases where the background task isn't getting created.

Flags: needinfo?(mozilla)

(In reply to Mike Kaply [:mkaply] from comment #3)

This wouldn't policy related, it would be some other documentation (or application?) that explained to focus how they can create the background task themselves.

We have documentation though, here. I do see that step 3 is phrased a little oddly to suggest that you need to change a setting to what is already its default value, which is a tad odd. Maybe we should be more explicit that if that is already the setting, you just have to run Firefox and let it do its thing?

But other than that, it seems like we already have exactly what you are describing.

People understand the profile requirement but it seems like there are cases where the background task isn't getting created.

If they fulfill all the requirements but the task isn't being created, that sounds like a bug that we should definitely fix. But this report is the first I've heard of it.

Sorry, I wasn't clear. They want instructions that don't involve using Firefox. Like how do they manually create the background task.

They want to use policy (not Firefox policy, Windows policy) to create the background task and not rely on Firefox.

(In reply to Mike Kaply [:mkaply] from comment #5)

Sorry, I wasn't clear. They want instructions that don't involve using Firefox. Like how do they manually create the background task.

I'm going to go ahead and say that we are not going to try to create instructions for how to manually recreate the background task. The task is not static. We are already on version 4 (or 5, depending on how you count it), and making sure that such specific documentation stays exactly synchronized with our code is not something we are well set up to do. The task definition should stay in a single place and not be duplicated, including by documentation. Any solution to this problem should be a code-based solution.

They want to use policy (not Firefox policy, Windows policy) to create the background task and not rely on Firefox.

Right, this was my question in the first place.

I don't really have any idea how this is meant to work. How can we do, well, anything by only setting a policy? We could certainly create, like, a background task or something that would register the Background Update Task, but is there a way to invoke it by just setting a policy and never actually running Firefox?

Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

I do have one potential idea for something like manually creating the task. I believe that tasks can be represented as XML. Perhaps we could change our task registration to use such XML instead of the current method and check the XML directly into the tree. Then the documentation could potentially link to that file and give instructions on how to install it?

I don't actually know how reasonable this is. I'm kinda just brainstorming. But I suspect it would be possible.

I am still not aware of a way to make progress on doing this via Windows policy though.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #6)

(In reply to Mike Kaply [:mkaply] from comment #5)

Sorry, I wasn't clear. They want instructions that don't involve using Firefox. Like how do they manually create the background task.

I'm going to go ahead and say that we are not going to try to create instructions for how to manually recreate the background task. The task is not static. We are already on version 4 (or 5, depending on how you count it), and making sure that such specific documentation stays exactly synchronized with our code is not something we are well set up to do. The task definition should stay in a single place and not be duplicated, including by documentation. Any solution to this problem should be a code-based solution.

The place where we create the background update task (around here) could itself be exposed as a background task, something like:

firefox.exe --backgroundtask backgroundupdate register-task ...

That would satisfy the task definition updating requirements, and would avoid duplication.

The issue that I foresee is that right now, the background update task assumes a default browsing profile exists and is accessible to the task itself. For users that never run Firefox, that simply isn't a valid assumption. Unwinding that assumption would take significant thought and some time.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #2)

That doesn't sound like the expected behavior. Could you please enable app.update.log in about:config, open the browser console (Control+Shift+J), set the filter to AUS:, reproduce this bug, and attach the resulting console messages to this bug so that I can see what's going on?

I will try to reproduce by deleting the task. I don't know if I'll be able to get into the same state as it was before. This user profile is a few decades old (pre-Firefox) and has been used across completely different platforms, so could've ended up in this state through some weird chain of Firefox settings changes throughout the years. Unfortunately I did not capture what the settings were yesterday before I finally managed to get the Firefox Background Update task created.

But even before I try, the more I look at this Firefox Background Update task the more confusing and puzzling the whole thing looks. The task did not exist yesterday, until I managed to finally get it created last night by following the steps I outlined in the first post. This morning, while looking at it closer and trying to Run it manually on demand a few times, I noticed a number of things:

a. It shows Last Run Time as being 2 weeks ago 2024-01-12.
c. Task trigger is dated 2 years ago 2022-03-06.
d. Last Run Result is: (0xC000026B).
c. When running, the task uses a privileged Admin account, not the normal user account that run Firefox during the above steps that triggered its creation (it was really late, but I don't think I executed Firefox with "run as administrator" last night).
d. The task is configured to "Run only when user is logged on".

This raises a number of questions:

  • Does this mean the task existed before and then somehow disappearted 2 weeks ago (but preserved prior execution history)?
  • Is 2022-03-06 a hardcoded trigger date during task creation?
  • Task seems to be failing to run when triggered either automatically or manually (I haven't found what 0xC000026B code means). Is this because it's configured to run only when Admin user happens to be logged in during trigger time (which is almost never)?

Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

Are you referring to Firefox profile or Windows user profile for this hard requirement?
Or both, because one implies the other?
Or default Firefox profile within each Windows user profile?
Or does Firefox nominate a specific Firefox profile inside a specific Windows user profile as being default and remembers it in some system-wide setting somewhere, like HKLM registry?

Is this related to the "Run only when user is logged on" task setting?
Is the task configured to run using Admin account because Admin was used to install Firefox initially at some point?
I doubt that is the case as I'm pretty sure this Admin account was created after Firefox was already installed/used.

I would think configuring this task to "Run whether user is logged on or not" would be a lot more preferable than the current "Run only when user is logged on" setting. Or would this break the default profile hard requirement you are referring to?

(In reply to Alexey Chernyak from comment #9)

c. When running, the task uses a privileged Admin account, not the normal user account that run Firefox during the above steps that triggered its creation (it was really late, but I don't think I executed Firefox with "run as administrator" last night).

It should register the task as the current user when Firefox ran. If you clicked "Run as Administrator" as a non-administrator user and then selected another account to run as, it would have been registered as that user. But if you clicked "Run as Administrator" from an administrator account, this would still run as the account of the logged-in user.

This raises a number of questions:

  • Does this mean the task existed before and then somehow disappearted 2 weeks ago (but preserved prior execution history)?
  • Is 2022-03-06 a hardcoded trigger date during task creation?

That all seems pretty weird; I don't know what to tell you about that. I have also seen some weird timestamps in the Task Scheduler. At this point I sorta just don't trust them, but I don't think I've seen ones this wonky before.

  • Task seems to be failing to run when triggered either automatically or manually (I haven't found what 0xC000026B code means). Is this because it's configured to run only when Admin user happens to be logged in during trigger time (which is almost never)?

It looks like this corresponds to STATUS_DLL_INIT_FAILED_LOGOFF, which I believe means that the user was logged out or in the process of logging out the last time it tried to run.

Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

Are you referring to Firefox profile or Windows user profile for this hard requirement?

Firefox profile. I guess you most likely need a Windows user profile too, but more logistically than because we imposed such a check/requirement.

Or does Firefox nominate a specific Firefox profile inside a specific Windows user profile as being default and remembers it in some system-wide setting somewhere, like HKLM registry?

There is an INI file in the %APPDATA% directory that specifies what profiles are available and which (if any) is the default. You can access a GUI to view/change this information by either running firefox -p or by navigating Firefox to about:profiles.

Is this related to the "Run only when user is logged on" task setting?

I'm having a hard time following what "this" is referring to. But it will only run when the user that registers it is logged in, yes.

Is the task configured to run using Admin account because Admin was used to install Firefox initially at some point?

No. It shouldn't matter what user installs Firefox.

I would think configuring this task to "Run whether user is logged on or not" would be a lot more preferable than the current "Run only when user is logged on" setting. Or would this break the default profile hard requirement you are referring to?

Yes, we currently do not have the capability to update without a user being logged in.

Just to throw out one other idea here, we could add an installer flag that would register the task on installation. But there are some obvious drawbacks: (a) it would only register it as the user account that ran the installer, and (b) we would have to address the Firefox profile requirement for this to really be useful in any meaningful way.

Attached file Firefox-Bug-1876302.txt —

After deleting the Firefox Background Update task in Task Scheduler, I don't know how to recreate it again.
Toggling settings doesn't do it, so I don't know how I recreated it yesterday.

Also in about:config I'm seeing app.update.auto.migrated setting but no app.update.auto which I thought should be there.

In the log I came across these 2 errors, and nothing else:

AUS:SVC gCanStageUpdatesSession - unable to stage updates. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: resource://gre/modules/UpdateService.sys.mjs :: testWriteAccess :: line 544" data: no]

AUS:SVC UpdateManager:_loadXMLFileIntoArray - XML file does not exist. path: C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\308046B0AF4A39CB\active-update.xml

See all settings and log in the attached file.

Flags: needinfo?(alexeyc2003)

(In reply to Alexey Chernyak from comment #11)

Created attachment 9376421 [details]
Firefox-Bug-1876302.txt

After deleting the Firefox Background Update task in Task Scheduler, I don't know how to recreate it again.
Toggling settings doesn't do it, so I don't know how I recreated it yesterday.

Also in about:config I'm seeing app.update.auto.migrated setting but no app.update.auto which I thought should be there.

In the log I came across these 2 errors, and nothing else:

AUS:SVC gCanStageUpdatesSession - unable to stage updates. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: resource://gre/modules/UpdateService.sys.mjs :: testWriteAccess :: line 544" data: no]

AUS:SVC UpdateManager:_loadXMLFileIntoArray - XML file does not exist. path: C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\308046B0AF4A39CB\active-update.xml

See all settings and log in the attached file.

You can see what's happening with task scheduling by setting Gecko string preference app.update.background.loglevel to be debug, and then flipping one of the prefs. You can also look at the app.update.background.previous.reasons preference to see what Firefox thinks is stopping it from scheduling the background update task.

Flags: needinfo?(alexeyc2003)
Attached file Firefox-Bug-1876302-debug.txt —

Here's a full Browser Console log with app.update.background.loglevel set to debug and no filtering, while toggling all Firefox Updates GUI Settings.
This includes some additional BackgroundUpdate log entries.
I've also updated the Execution State notes.

I can see these 2 log entries:

AUS:SVC getCanUseBits - Not using BITS because of proxy usage

BackgroundUpdate: maybeScheduleBackgroundUpdateTask: not scheduling background update: '["on Windows but cannot usually use BITS"]' BackgroundUpdate.sys.mjs:554

I checked, BITS is running and there is no proxy configured.

(In reply to Mike Kaply [:mkaply] from comment #1)

We've had quite a few people request the ability to create the background task independent of using Firefox.

We should create a simple way to do this or document how to do it.

The BackgroundAppUpdate policy was added to disable background update, not enable it.

We absolutely need a way to be able to control this task creation with GPO/LGPO policy.
i.e. any time Firefox is executed and Firefox Background Update task is missing in Task Scheduler when GPO policy requires it - it should recreate the task.

(In reply to Nick Alexander :nalexander [he/him] from comment #8)

The place where we create the background update task (around here) could itself be exposed as a background task, something like:

firefox.exe --backgroundtask backgroundupdate register-task ...

That would satisfy the task definition updating requirements, and would avoid duplication.

Something like this would be really useful for users that don't play with GPO. Right now I don't understand what I need to do to create this task at all.

But whatever the way is, it also needs to be triggerable by GPO policy as well.

Flags: needinfo?(alexeyc2003)

Can you please navigate to about:preferences, scroll down to the "Network Settings" section at the bottom, click "Settings", and tell me which of the radio buttons is selected: "No proxy", "Autodetect proxy settings for this network", "Use system proxy settings", "Manual proxy configuration", or "Automatic proxy configuration URL"?

(In reply to Alexey Chernyak from comment #13)

We absolutely need a way to be able to control this task creation with GPO/LGPO policy.
i.e. any time Firefox is executed and Firefox Background Update task is missing in Task Scheduler when GPO policy requires it - it should recreate the task.

Firefox already checks shortly after launch for the existence of this task and registers or unregisters it appropriately, depending on whether it determines that the installation is eligible to use the Background Update Task. The problem you are having is that it is determining that your installation is not eligible because of proxy usage.

Flags: needinfo?(alexeyc2003)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #14)

Can you please navigate to about:preferences, scroll down to the "Network Settings" section at the bottom, click "Settings", and tell me which of the radio buttons is selected: "No proxy", "Autodetect proxy settings for this network", "Use system proxy settings", "Manual proxy configuration", or "Automatic proxy configuration URL"?

My setting is "No proxy".

I have network.trr.mode set at 3 with DoH being used for Max Protection.
Could this be somehow impacting proxy detection code?

(In reply to Robin Steuber (they/them) [:bytesized] from comment #10)

Even assuming that there is, it is currently a hard requirement that Firefox have a default profile that has been used at least once in order to run Background Update. I'll have to think about if there is any way to get around this.

Are you referring to Firefox profile or Windows user profile for this hard requirement?
Or both, because one implies the other?
Or default Firefox profile within each Windows user profile?
Or does Firefox nominate a specific Firefox profile inside a specific Windows user profile as being default and remembers it in some system-wide setting somewhere, like HKLM registry?

There is an INI file in the %APPDATA% directory that specifies what profiles are available and which (if any) is the default. You can access a GUI to view/change this information by either running firefox -p or by navigating Firefox to about:profiles.

The %APPDATA% is specific per each Windows user profile, so each Windows user profile will have it's own INI file specifying default Firefox profile.
So it sounds like the hard requirement for the Firefox Background Update task creation is that Firefox is executed with any of the default Firefox profiles under any of the Windows user profiles?

Flags: needinfo?(alexeyc2003)

(In reply to Alexey Chernyak from comment #15)

My setting is "No proxy".

This is the problem. As stated in the documentation for enabling this feature:

Firefox connection settings must be configured to use the system proxy (this is the default).

That is not the proxy setting that you are using. If you switch it to "Use system proxy settings", can you now register the task successfully?

The %APPDATA% is specific per each Windows user profile, so each Windows user profile will have it's own INI file specifying default Firefox profile.
So it sounds like the hard requirement for the Firefox Background Update task creation is that Firefox is executed with any of the default Firefox profiles under any of the Windows user profiles?

Launching Firefox as the default Firefox profile will (if eligible) register the Background Update task for that user account. As touched on earlier, the task only runs for the user it is registered as. Also, we recently fixed Bug 1830071 in version 112, so versions prior to that will not be able to register background update tasks as multiple users. We are in the process of looking into uplifting that change to ESR115, but that is still in-progress.

Flags: needinfo?(alexeyc2003)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #16)

(In reply to Alexey Chernyak from comment #15)

My setting is "No proxy".

This is the problem. As stated in the documentation for enabling this feature:

Firefox connection settings must be configured to use the system proxy (this is the default).

That is not the proxy setting that you are using. If you switch it to "Use system proxy settings", can you now register the task successfully?

After trying different things, changing to "Use system proxy settings" did the trick.
Whenever unprivileged user runs Firefox now, two Firefox Background Update tasks get created one for unprivileged user and one for admin user.
Also manually running both Firefox Background Update tasks seems to work now with result 0x15.

The way to do it with GPO seems to be very convoluted.

Enabling Application Autoupdate and Background updater in GPO didn't do anything because of my proxy settings.
Enabling and setting Connection Type to Use system proxy settings in GPO also had no effect until I also enabled Do not allow proxy settings to be changed.

So looks like to get this to work all 4 GPO settings need to be enabled.
This needs to be documented better in both URLs specified in this bug.

With these 4 GPO settings, the user is not able to change in Settings GUI anything except for the Use a background service to install updates tickbox - which doesn't look right.

I'm going to untick it, close Firefox and check if the task(s) get executed in the morning.

Flags: needinfo?(alexeyc2003)
Summary: Application Autoupdate (AppAutoUpdate / app.update.auto) and Background updater (BackgroundAppUpdate / app.update.background.enabled) GPO Enterprise policies don't create / block creation of the Firefox Background Update job in Windows Task Scheduler → Application Autoupdate (AppAutoUpdate / app.update.auto) and Background updater (BackgroundAppUpdate / app.update.background.enabled) GPO Enterprise policies don't create the Firefox Background Update job in Windows Task Scheduler

Enabling and setting Connection Type to Use system proxy settings in GPO also had no effect until I also enabled Do not allow proxy settings to be changed.

Policy sets the default value only which can be overridden by a user, so if you had it manually set to another value, it would use that one. Checking "Do not allow proxy settings to be changed" locks it so that a user can't change it and forces that value.

With these 4 GPO settings, the user is not able to change in Settings GUI anything except for the Use a background service to install updates tickbox - which doesn't look right.

Are you saying this should be disabled as well? IF so, I agree.

I do think we need to show error messages on the console when we can't create the background task for some reason (proxy for instance)

I do think we need to show error messages on the console when we can't create the background task for some reason (proxy for instance)

There are lots of situations where we don't schedule background tasks; most of them aren't errors and can't meaningfully be addressed by the user. (For example, the most common is that they're using a langpack.) If we spam the console they'll see an "error" every time they launch Firefox.

(In reply to Alexey Chernyak from comment #17)

With these 4 GPO settings, the user is not able to change in Settings GUI anything except for the Use a background service to install updates tickbox - which doesn't look right.

I'm going to untick it, close Firefox and check if the task(s) get executed in the morning.

Unchecking that will result in the background task not updating and, eventually, the task itself being unregistered.

Severity: -- → S3

(In reply to Robin Steuber (they/them) [:bytesized] from comment #20)

I'm going to untick it, close Firefox and check if the task(s) get executed in the morning.

Unchecking that will result in the background task not updating and, eventually, the task itself being unregistered.

Looks like the Firefox Background Update task has run.
Yesterday after creation it had Last Run Result of 0x41303.
This morning it has Last Run Result of 0x0 for both tasks.
Does this mean success? If so, then unticked Use a background service to install updates has no effect and GPO settings override it.

(In reply to Nick Alexander :nalexander [he/him] from comment #19)

There are lots of situations where we don't schedule background tasks; most of them aren't errors and can't meaningfully be addressed by the user. (For example, the most common is that they're using a langpack.) If we spam the console they'll see an "error" every time they launch Firefox.

Fundamentally I think the goal should be to simplify this functionality and remove most of the dependencies that create these situations, so that this is more streamlined, robust and easier managed. This really should work regardless of proxy settings and langpacks should be handled by the upgrade itself, rather than being an outright blocker.

Until then, I guess at the very least the following needs to be done:

  • Update the GPO documentation in the URL of this bug for BackgroundAppUpdate to mention the 2 proxy GPO settings that also need to be enabled for it to work.
  • Update the KB article in this bug's See also to describe the 4 GPO settings that need to be enabled.
  • Update ADMX descriptions for Background updater and Connection Type to mention the GPO settings that also need to be enabled for them to work.
  • Have Use a background service to install updates GUI setting being disabled by GPO like the rest of them.

Also do we really need multiple Firefox Background Update tasks created under different security contexts?
Shouldn't Mozilla Maintenance Service creating just one task under the Admin account security context be sufficient?

The checkbox just got removed, so we're good there.

I'll update the Background Update GPO to mention the SUMO article as to reasons why it wouldn't work, but you don't necessarily need to set the GPO to make the background updater work, you just can't have a proxy set.

(In reply to Mike Kaply [:mkaply] from comment #22)

I'll update the Background Update GPO to mention the SUMO article as to reasons why it wouldn't work, but you don't necessarily need to set the GPO to make the background updater work, you just can't have a proxy set.

In case of the proxy settings the user is able to override GPO, and as an admin you don't want that.
The GPO should be overriding the user settings, not the other way around.

But Background update really should be configured regardless of proxy settings.
It should try using the proxy settings whatever they may be, not just bailing out.
For all intents and purposes my No proxy setting is identical to my Use system proxy settings.
It should just work.

This Background update functionality needs to be robustly controlled by an admin.
This becomes important especially for use of Firefox in Corporate and Government environments.
For example policy/customer/tender/legal requirement to apply vulnerability patches within 48 hours of their release.
You want automatic patching to be easily configured and to have assurance that it is enforced.

Otherwise when unpatched instances of Firefox get discovered during an audit, it would be easier to uninstall it from all workstations, than try to troubleshoot why it's not patching as per GPO.

At the very least ADMX descriptions should be exhaustive enough to make it easy to identify what else needs to be done to make sure automatic updates work.

The GPO should be overriding the user settings, not the other way around.

It does if you lock it. You can either set the default value or force it.

But Background update really should be configured regardless of proxy settings.
It should try using the proxy settings whatever they may be, not just bailing out.

I'm looking into why certain proxy settings are ignored when they shouldn't be.

(In reply to Alexey Chernyak from comment #23)

But Background update really should be configured regardless of proxy settings.
It should try using the proxy settings whatever they may be, not just bailing out.

Ignoring user configuration is not the right thing to do here. Leaving aside the issue of how much this would upset users, proxy configuration can be a matter of privacy, safety, and money. If Firefox was configured not to reveal itself over the unproxied connection, we can't just ignore that when it is inconvenient. Doing so could compromise privacy and potentially even safety. For corporate environments that require a proxy, we could get those employees in trouble.

Using a proxy can also involve using a different physical connection that may have a different cost to use. It's unreasonable for Firefox to ignore configuration and make the decision to use a link that it wasn't configured to use and doesn't know the cost of.

It's the user's responsibility to provide a good configuration and Firefox's responsibility to respect it.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #25)

Ignoring user configuration is not the right thing to do here.

Couldn't agree more, and herein lies the problem.

Right now Firefox Background Update functionality ignores the user's proxy settings as well as its own background update settings.
It just refuses to use the configured proxy, and also refuses to function altogether.
What's even worse is it refuses to use these settings silently, without alerting the user, or asking the user for any confirmations.

It ignores the user's configuration for running updates in the background, without telling the user.

Similarly it ignores the admin's GPO configuration, without GPO documentation informing admin that their policy can be ignored.

Both users and administrators are left vulnerable to security risks, expecting Firefox to honour their configuration, and unaware Firefox silently ignores it.

I took a look at the documentation for the BackgroundAppUpdate policy. Perhaps the documentation should be expanded/clarified, but it looks to me like it is technically correct as-is.

Enable or disable automatic application update in the background, when the application is not running.

If set to true, application updates may be installed (without user approval) in the background, even when the application is not running. The operating system might still require approval.

If set to false, the application will not try to install updates when the application is not running.

If you have disabled updates via DisableAppUpdate or disabled automatic updates via AppAutoUpdate, this policy has no effect.

It specifies that the updates "may" (not "will") be installed in the background. I feel like the last sentence makes it pretty clear that nothing is being forcibly enabled; this is one piece of configuration in the constellation of options that are available.

Failing to register the Background Update task when this policy is enabled does not look, to me, like we are ignoring your configuration. We are simply doing our best to comply with all the options you have specified. Unfortunately, the combination specified is currently outside the available capabilities. Which we have documented.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #27)

It specifies that the updates "may" (not "will") be installed in the background. I feel like the last sentence makes it pretty clear that nothing is being forcibly enabled; this is one piece of configuration in the constellation of options that are available.

It's not really about semantics of descriptions and their technical correctness.
It's about the purpose of things and their implications.
The purpose of policies is to enforce compliance.
Which is why GPOs shouldn't be open to interpretation.

In the context of policies, the interpretation of "may" in that description more appropriately means that updates installation is allowed without user approval, not whether installation may or may not happen.

The purpose of policies is to forcibly enable or disable things, and shouldn't be confused with configuration settings.

When it comes to implications of Security-relevant policies such as this one, it becomes a matter of not just an auditable compliance enforcement, but also a matter of security assurance and risk mitigation, with potential impacts at stake ranging from financial loss to loss of human lives being dependant on that policy.

This is the difference between enterprise-ready products, and products unsuitable for enterprise use.
I filed this bug under the Enterprise Policies component, not under the Application Update component for that exact reason.
The Summary description of this bug is a real problem for administrators and their organisations when they try to use Firefox.
Hope that makes sense.

(In reply to Mike Kaply [:mkaply] from comment #22)

The checkbox just got removed, so we're good there.

I'll update the Background Update GPO to mention the SUMO article as to reasons why it wouldn't work, but you don't necessarily need to set the GPO to make the background updater work, you just can't have a proxy set.

The Use a background service to install updates checkbox is still not hidden in v122.0.1.

Admins need to be able to control this regardless of whether or not users have a proxy set. So Background updater description should mention the need to also enforce Connection Type and Do not allow proxy settings to be changed policies for it to work.

Since the features in question are currently doing exactly what they are designed to do, I'm going to close this bug. Sorry that this doesn't match with how you want these features to work.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID

I will be updating the policy docs to make some things more clear.

(In reply to Mike Kaply [:mkaply] from comment #30)

I will be updating the policy docs to make some things more clear.

Thanks, Mike!
Would be good to update descriptions in policy templates as well - admins typically rely on that first and foremost.
Also any admin searching for Firefox autoupdates would get the KB article as the first result in Google. Would be good for this KB article to mention the relevant policies and provide links to policies doco and policy templates downloads.

(In reply to Mike Kaply [:mkaply] from comment #24)

I'm looking into why certain proxy settings are ignored when they shouldn't be.

Any luck with this? Seems like a cornerstone of this bug.
May need to rework the design to fix this.

Flags: needinfo?(mozilla)

Any luck with this? Seems like a cornerstone of this bug.
May need to rework the design to fix this.

After discussion with the team, they are comfortable with the choices they made as to when to use the proxy information for the background update task.

Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: