[OTHER] dom.webserial.enabled (unintentionally) locked to false #312

degausser commented 2026年06月10日 22:26:04 +02:00

the implication here is not entirely correct: if any policies are defined (as they are in phoenix, shipping its own policies.json), dom.webserial.enabled is locked to false*. if fingerprinting truly is a concern, with the webserial api turned on by default in desktop release builds, or the api support is intended to be left user-modifiable by default (aka defaultPref instead of lockPref), DefaultSerialGuardSetting: 3 should be set as policy, which would ironically allow the api by default (dom.webserial.enabled->true), and then it would be gated by abovementioned prefs. the policy should not be set on android, since false is the default on mobile and should not be overridden; the value being locked to false by policy usage is not an issue there (that is, until the default changes to true everywhere).

*EDIT:
in ff152+, the pref might no longer be locked to false by policy usage, just default false in that case (it is locked in 151); the fingerprinting angle remains the same. so for 152, explicitly setting defaultPref("dom.webserial.enabled", true); // [NO-ANDROID] [DEFAULT] might be enough.

https://codeberg.org/celenity/Phoenix/src/commit/d3cc0d78b3533d409e181c8c0fec6964c835cf54/phoenix-unified.cfg#L3871-3873 the implication here is not entirely correct: if _any policies are defined_ (as they are in phoenix, shipping its own `policies.json`), `dom.webserial.enabled` is [locked to false](https://hg-edge.mozilla.org/mozilla-central/rev/69d447bb852a)*. if fingerprinting truly is a concern, with the webserial api [turned on by default](https://bugzilla.mozilla.org/show_bug.cgi?id=2029625) in desktop release builds, or the api support is intended to be left user-modifiable by default (aka `defaultPref` instead of `lockPref`), [`DefaultSerialGuardSetting: 3`](https://firefox-admin-docs.mozilla.org/reference/policies/defaultserialguardsetting/) should be set as policy, which would ironically allow the api by default (`dom.webserial.enabled->true`), and then it would be gated by abovementioned prefs. the policy should not be set on android, since `false` is the default [on mobile](https://searchfox.org/firefox-main/source/modules/libpref/init/StaticPrefList.yaml#6027) and should not be overridden; the value being locked to `false` by policy usage is not an issue there (that is, until the default changes to `true` everywhere). *EDIT: in ff152+, the pref might no longer be [locked to false](https://bugzilla.mozilla.org/show_bug.cgi?id=2042826) by policy usage, just default `false` in that case (it is locked in 151); the fingerprinting angle remains the same. so for 152, explicitly setting `defaultPref("dom.webserial.enabled", true); // [NO-ANDROID] [DEFAULT]` might be enough.

celenity commented 2026年06月11日 00:42:23 +02:00

@degausser Thank you for letting me know! I'm surprised by this behavior, this was definitely something I missed.

if fingerprinting truly is a concern, with the webserial api turned on by default in desktop release builds, or the api support is intended to be left user-modifiable by default (aka defaultPref instead of lockPref), DefaultSerialGuardSetting: 3 should be set as policy, which would ironically allow the api by default (dom.webserial.enabled->true), and then it would be gated by abovementioned prefs.

Yeah, the intention is basically to disable/block usage of the API by default, while allowing users to override/re-enable it if desired.

The problem with setting dom.webserial.enabled to false directly is that it's fingerprintable (outside of Android currently), due to it impacting the DOM (as it controls the exposure of ex. Serial and SerialPort) - so it adds an extra vector for us to stand out from stock Firefox. As long as dom.webserial.gated is set to true (Maybe we should lock that pref, TBH?), setting permissions.default.serial to 2 effectively achieves the same result, just without impacting the DOM (and thus minimizing the impact on fingerprinting).

in ff152+, the pref might no longer be locked to false by policy usage, just default false in that case (it is locked in 151); the fingerprinting angle remains the same. so for 152, explicitly setting defaultPref("dom.webserial.enabled", true); // [NO-ANDROID] [DEFAULT] might be enough.

Unfortunately, I don't think it will be - IIRC, based on testing in the past, prefs set by policies seem to take priority over prefs set by us (at phoenix.cfg), will test to confirm this is still the case though.

It's annoying how this is handled, wish there was a way we could avoid setting it at all via policies, but it seems to be hardcoded. So I think the best solution for now will be your idea of setting DefaultSerialGuardSetting to 3 for desktop. Will add for next release!

@degausser Thank you for letting me know! I'm surprised by this behavior, this was definitely something I missed. > if fingerprinting truly is a concern, with the webserial api [turned on by default](https://bugzilla.mozilla.org/show_bug.cgi?id=2029625) in desktop release builds, or the api support is intended to be left user-modifiable by default (aka `defaultPref` instead of `lockPref`), [`DefaultSerialGuardSetting: 3`](https://firefox-admin-docs.mozilla.org/reference/policies/defaultserialguardsetting/) should be set as policy, which would ironically allow the api by default (`dom.webserial.enabled->true`), and then it would be gated by abovementioned prefs. Yeah, the intention is basically to disable/block usage of the API by default, while allowing users to override/re-enable it if desired. The problem with setting `dom.webserial.enabled` to `false` directly is that it's fingerprintable *(outside of Android currently)*, due to it impacting the `DOM` *(as it controls the exposure of ex. `Serial` and `SerialPort`)* - so it adds an extra vector for us to stand out from stock Firefox. As long as `dom.webserial.gated` is set to `true` *(Maybe we should lock that pref, TBH?)*, setting `permissions.default.serial` to `2` effectively achieves the same result, just without impacting the `DOM` *(and thus minimizing the impact on fingerprinting)*. > in ff152+, the pref might no longer be locked to false by policy usage, just default false in that case (it is locked in 151); the fingerprinting angle remains the same. so for 152, explicitly setting defaultPref("dom.webserial.enabled", true); // [NO-ANDROID] [DEFAULT] might be enough. Unfortunately, I don't think it will be - IIRC, based on testing in the past, prefs set by policies seem to take priority over prefs set by us *(at `phoenix.cfg`)*, will test to confirm this is still the case though. It's annoying how this is handled, wish there was a way we could avoid setting it at all via policies, but it seems to be hardcoded. So I think the best solution for now will be your idea of setting `DefaultSerialGuardSetting` to `3` for desktop. Will add for next release!