Closed Bug 1813789 Opened 3 years ago Closed 1 year ago

See if the translations worker can be moved from a ChromeWorker to an unprivileged Worker

Categories

(Firefox :: Translations, task, P3)

task

Tracking

()

RESOLVED WONTFIX

People

(Reporter: gregtatum, Unassigned)

Details

Any worker created in a chrome-privileged principal will inherit the privileges. The translations worker doesn't need chrome privileges since it's just running a wasm blob that transforms a string into a string.

Here you can see the various ChromeUtils a ChromeWorker has access to: https://searchfox.org/mozilla-central/rev/7a9e3bbab8f81c2cbc72a394047f948da9cfef9a/dom/chrome-webidl/ChromeUtils.webidl#73-260

It would be nice if we could figure out a way to load a Worker without the privileges. One immediate issue with accomplishing this is the same-origin rule gets in the way of loading a resource:// URL from a content page.

For instance, in about:translations the origin is reported as "null" and invoking the worker on the content-side of the page causes a same-origin error to be thrown when loading the worker at a resource:// or chrome:// URL.

While about:translations we are in control of the content side of the page, on the general web we are not, and so this may not be feasible for the Worker to run on the content side, but I'm not sure. This needs to be investigated, as it would be a clear security win if we can lock down the Worker.

This blocks MVP so that we can at least decide on this through a security review, plus check on the feasibility.

Blocks: 1820214
Blocks: 1820240
No longer blocks: 1820240

I'm taking this off the Desktop MVP since I don't think it blocks release, and was a nice-to-have.

No longer blocks: 1820214
No longer blocks: fx-translation

I would still like to de-privilege the single process code, and this issue is affecting the newer architecture, so it's still relevant.

At this point I'm fine keeping things in the ChromeWorker. It's proven beneficial to have access to things like addProfilerMarker. We're more directly in control of the inference engine these days, and it's all in Wasm.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.