With 1871376, we use PFetch for main thread fetch requests with keepalive flag. However, we do not support keepalive for ChromeWorker requests. This bug will investigate if we need to support keepalive for ChromeWorker requests.

Conceptually, all ChromeWorker code is system JS code and system JS code inherently has the ability to control the lifetime of any workers it creates[1]. Additionally, I think the only case system JS code's use cases would overlap with keepalive use cases would be something like telemetry, and the telemetry mechanism already deals with all relevant lifetime issues (and has its own data delivery mechanism). So I don't know that the use case is something we explicitly need to support.

That said, I understand this bug to be filed in relation to the review comment https://phabricator.services.mozilla.com/D205720#7242813 on line 739 of dom/fetch/Fetch.cpp.

This interacts with the general concern that, as :nika frequently expresses, a major deficiency in our handling of the system principal is that we do not and should not trust the system principal in content processes in the same way that we trust the system principal in the parent process. (And the system principal in the privileged about process potentially exists somewhere in between?) We absolutely do not want to enable code in a content process to be able to use PFetch to create a channel in the parent process that could, for example, read the contents of file:///etc/passwd, effectively escaping the sandbox.

To the extent that we support the system principal in PFetch, we should likely be downgrading the system principal to the null principal when the request is received by the parent process. Of course, if there is code that already creates a principal that accurately reflects the capabilities a content process system principal should have, we should use that instead. (I am not sure what we do currently for PFetch as it relates to the system principal, it's quite possible we should change our behavior here.)

From a general implementation consistency perspective over the longer term, it does seem like we would want to use PFetch consistently unless there are security reasons not to.

I've cc'ed :nika for awareness of my mention of the system principal stuff, and :tjr as the filer of bug 1491018 and filer of most bugs that block bug 1670242.

1: Specifically they can create shutdown blockers to ensure the process and globals that own the worker can stay alive.