CMS, docs: verify whether Firefox and Safari can actually reach the media encoder

[johan-bell]

The CMS tells editors that encoding needs Chrome. Three places in the codebase assert it and none of them demonstrate it.

What is actually established

Chrome treats a public page reaching 127.0.0.1 as a private-network request: it sends Access-Control-Request-Private-Network: true on the preflight and drops the real request unless the response grants it. The encoder answers exactly that in api/src/cors.config.ts (privateNetworkAccessMiddleware), registered ahead of the CORS middleware.

That is the whole Chrome-specific mechanism, and it works.

The encoder's native "trust this site" dialog is a separate thing — its own origin allowlist, in the desktop app. It is not a browser feature and works anywhere.

What is not established

That other browsers cannot reach the encoder. The claim appears in:

• cms/src/util/mediaEncoder.ts — "Firefox and Safari do not implement the grant, so this is Chrome-only at time of writing."
• docs/guides/media-encoder-integration.md — "Use Chrome. Private-network access is Chrome-only at the time of writing."
• The CMS's own notice copy — "Encoding needs Chrome."

All hedged with "at the time of writing", none with a reproduction.

The reasoning is also backwards on its face: a browser that does not implement Private Network Access would not send the preflight and would not need the grant, so the request should succeed under ordinary CORS — which the encoder also answers. Not implementing PNA should mean fewer restrictions, not more.

The guide separately rules out the obvious alternative explanation: "An HTTPS dev CMS reaching http://127.0.0.1 is not blocked as mixed content — browsers treat loopback as potentially trustworthy."

So either there is a different, unwritten reason (Safari's own local-network restrictions are the likeliest candidate), or the claim traces back to a single failed test that became lore.

What to do

With the desktop encoder running, open a CMS on a public origin in Firefox and in Safari and try to encode. Record for each: whether the health check succeeds, whether POST /api/cms/sessions succeeds, whether the encoder's trust dialog appears, and the exact console error if it fails.

Why it matters

If Firefox works, we are telling editors to switch browsers for no reason, and the guide, two code comments and the notice copy should all say so. If it genuinely fails, nobody has written down why — and that reason belongs in the guide, because it is the thing a future reader will need.

Not urgent

The CMS degrades correctly either way. refreshAvailability consults the browser only after the health request fails, never before it, so a browser that reaches the encoder gets the working Encode button whatever its user agent says. A wrong assumption costs a slightly wrong message, not a locked-out editor.

[johan-bell]

The repo already contradicts itself, and the contradiction points the other way

luminary-media-convert/docs/security-review.md:75, dated 2026-08-18:

Firefox and Safari have no local-network gate today. Chrome's newer permission-based Local Network Access would block it, and an opaque origin cannot hold a permission.

That is stated while establishing the impact of finding 2.1 — an opaque-origin page opening a session on someone's encoder. The finding only works if Firefox and Safari can reach loopback from a web page. So the security review is asserting, in a context where being wrong would have understated a vulnerability, that Firefox and Safari are the permissive ones and Chrome is the restrictive one.

That is the exact opposite of what the CMS tells editors.

Both claims are two days apart in the same codebase, and they cannot both be true. The security review's version also matches the mechanics: Chrome is the browser that sends the private-network preflight and drops the request without a grant. A browser with no gate has nothing to drop.

Where this leaves it

The prior is now strongly against "Chrome only" — but a document is not a test, and neither of these was arrived at by trying it. The verification below is still the thing that settles it.

If Firefox works, four places need correcting: cms/src/util/mediaEncoder.ts, docs/guides/media-encoder-integration.md, the notice copy in cms/src/components/media/EncodeStatus.vue, and browserCanReachEncoder() in the CMS, which currently treats non-Chromium as the explanation for a failure.

[johan-bell]

Probed against a live encoder — the server is ruled out

Encoder running (packaged app, 127.0.0.1:31711). Three requests:

Probe	Result
Ordinary preflight, no PNA header — the shape Firefox and Safari send	204 with Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers. Fully granted.
Chrome's preflight, Access-Control-Request-Private-Network: true	Identical grant plus Access-Control-Allow-Private-Network: true
Real GET /api/cms/health with an Origin	200, ACAO present, {"status":"ok","apiVersion":"0.0.1"}

The private-network grant is purely additive. A browser that never sends the header still receives a complete, working CORS response. The encoder imposes nothing extra on non-Chrome browsers, which matches cors.config.spec.ts's "stays out of the way of an ordinary preflight".

So the server side is eliminated. If the Chrome-only claim is true at all, the cause is entirely browser-side.

What these probes do not settle

They were sent from http://localhost:4175 — loopback to loopback, which is not a private-network request in any browser. The claim concerns a public origin reaching 127.0.0.1, which is the only case Chrome gates and the only case where the browsers could differ.

The remaining test

With the encoder running, open the deployed CMS (a real https:// origin, not localhost) in Firefox and in Safari, and run in the console:

await fetch('http://127.0.0.1:31711/api/cms/health').then(r => r.json())

That is exactly what checkEncoderHealth does. Record for each browser: the result or the exact error, and whether the encoder's trust dialog appeared.