DRM cannot be enabled. open.spotify.com doesn't work

bugsbun commented

2025-05-09 02:43:47 +02:00

Confirmation

Please confirm that you have already checked the Website Compatibility wiki page (https://phoenix.celenity.dev/compat), and that this issue is NOT currently listed.

Which domain(s) are you experiencing this issue on?

open.spotify.com

What version of Phoenix are you using?

2025.04.27.1

What version of Firefox are you using with Phoenix?

138.0.1

What operating system are you experiencing this issue on?

Android

Other

No response

Please explain the issue you are experiencing.

It appears to be impossible to enable DRM via about:config. On Mull it works just fine.
Either you forcefully blocked it like a policies.json does or something else blocks it.

If you enable EME/Widevine, no approval request appears. Spotify loads without playing anything and returns to its error page sfter about a minute.

### Confirmation - [x] Please confirm that you have already checked the Website Compatibility wiki page (https://phoenix.celenity.dev/compat), and that this issue is NOT currently listed. ### Which domain(s) are you experiencing this issue on? open.spotify.com ### What version of Phoenix are you using? 2025.04.27.1 ### What version of Firefox are you using with Phoenix? 138.0.1 ### What operating system are you experiencing this issue on? Android ### Other _No response_ ### Please explain the issue you are experiencing. It appears to be impossible to enable DRM via about:config. On Mull it works just fine. Either you forcefully blocked it like a policies.json does or something else blocks it. If you enable EME/Widevine, no approval request appears. Spotify loads without playing anything and returns to its error page sfter about a minute.

bugsbun added the

web compat

label

2025-05-09 02:43:47 +02:00

celenity self-assigned this

2025-05-09 03:49:13 +02:00

celenity commented

2025-05-09 04:02:31 +02:00

Owner

Thanks for the report.

To confirm, the removal/disablement of DRM was intentional, and we don't provide any official support for it.

That being said:

On Mull it works just fine.

What specific preferences did you change on Mull for it to work?

We did recently disable the Widevine key system/integration with Android's MediaDrm API on IronFox, as we found that even with the EME preferences disabled, the Widevine module still appeared to be available/listed in about:support. I'm willing to consider un-doing that change (for folks like you who really want to use DRM at your own risk/discretion), but we'll need to first do research to ensure that the module is never active unless EME is explicitly enabled. I may file an issue on Bugzilla for this, since things are different on desktop (Ex. when setting the appropriate preferences, the Widevine module does actually disappear from about:support & about:addons...).

Regardless, I just went ahead and added open.spotify.com to the Web Compat page.

Thanks for the report. To confirm, the removal/disablement of DRM was intentional, and we don't provide any official support for it. That being said: > On Mull it works just fine. What specific preferences did you change on Mull for it to work? We did recently [disable the Widevine key system/integration with Android's `MediaDrm` API](https://gitlab.com/ironfox-oss/IronFox/-/blob/dev/patches/gecko-liberate.patch#L28) on IronFox, as we found that even with the EME preferences disabled, the Widevine module still appeared to be available/listed in `about:support`. I'm willing to consider un-doing that change *(for folks like you who really want to use DRM at your own risk/discretion)*, but we'll need to first do research to ensure that the module is **never** active unless EME is explicitly enabled. I may file an issue on Bugzilla for this, since things are different on desktop *(Ex. when setting the appropriate preferences, the Widevine module does actually disappear from `about:support` & `about:addons`...)*. Regardless, I just went ahead and added `open.spotify.com` to the [Web Compat page](https://phoenix.celenity.dev/compat).

bugsbun commented

2025-05-09 16:31:09 +02:00

Author

Yeah, I tested 137.0.2 and it runs just like Mull. It's enough to set media.eme.enabled and media.mediadrm-widevinecdm.visible to true and keep everything else as false, but by default on Mull you only need to enable eme.enabled.

On that version of Ironfox you can also set media.gmp-widevinecdm.enable and media.gmp-widevinecdm.visible to true instead of mediadrm.

at your own risk/discretion

The alternative for most folks is to use a secondary, usually less hardened browser or the app of the service that makes hiding anything in the first place moot.

Moreover, it's inappropriate to use webcompat as a whitelist. It's meant to fix bugs and incompatibilities with the default config, not gatekeep features.

Yeah, I tested 137.0.2 and it runs just like Mull. It's enough to set `media.eme.enabled` and `media.mediadrm-widevinecdm.visible` to true and keep everything else as false, but by default on Mull you only need to enable eme.enabled. On that version of Ironfox you can also set `media.gmp-widevinecdm.enable` and `media.gmp-widevinecdm.visible` to true instead of mediadrm. >at your own risk/discretion The alternative for most folks is to use a secondary, usually less hardened browser or the app of the service that makes hiding anything in the first place moot. Moreover, it's inappropriate to use webcompat as a whitelist. It's meant to fix bugs and incompatibilities with the default config, not gatekeep features.

👍 1

celenity commented

2025-05-09 20:07:54 +02:00

Owner

On that version of Ironfox you can also set media.gmp-widevinecdm.enable and media.gmp-widevinecdm.visible to true instead of mediadrm.

So to confirm I understood you correctly, setting either media.eme.enabled andmedia.mediadrm-widevinecdm.visible to true or setting media.eme.enabled, media.gmp-widevinecdm.enabled, and media.gmp-widevinecdm.visible to true fixes the issue?

The alternative for most folks is to use a secondary, usually less hardened browser or the app of the service that makes hiding anything in the first place moot.

True, but I'm not convinced that's enough of a justification for us to enable/support a technology designed with the explicit intent and purpose to harm users (and one that includes the privacy and security concerns of DRM...).

As I stated though, I'm fine reverting the recent change if we can ensure the module is fully inactive unless the prefs are toggled. After all, one of this project's main goals is to respect the freedom of users - even when it comes to things like this that we don't support, recommended, and are strongly opposed to (That doesn't mean we have to make it easy though or ex. expose it in the UI - but I think it's acceptable to allow it to work with about:config, as long as there aren't implications as previously stated).

Moreover, it's inappropriate to use webcompat as a whitelist. It's meant to fix bugs and incompatibilities with the default config, not gatekeep features.

I don't understand what you're referring to here; the Web Compat page is meant to document websites with known issues/breakage, so that users are aware and can understand why something doesn't work (and how they can fix/workaround it). It's not a whitelist or gatekeeping, perhaps you're referring to something else?

> On that version of Ironfox you can also set `media.gmp-widevinecdm.enable` and `media.gmp-widevinecdm.visible` to true instead of mediadrm. So to confirm I understood you correctly, setting either `media.eme.enabled` *and*`media.mediadrm-widevinecdm.visible` to `true` **or** setting `media.eme.enabled`, `media.gmp-widevinecdm.enabled`, *and* `media.gmp-widevinecdm.visible` to `true` fixes the issue? > The alternative for most folks is to use a secondary, usually less hardened browser or the app of the service that makes hiding anything in the first place moot. True, but I'm not convinced that's enough of a justification for us to enable/support a technology designed with the explicit intent and purpose to harm users *(and one that includes the privacy and security concerns of DRM...)*. As I stated though, I'm fine reverting the recent change if we can ensure the module is fully inactive unless the prefs are toggled. After all, one of this project's main goals is to respect the freedom of users - even when it comes to things like this that we don't support, recommended, and are strongly opposed to *(That doesn't mean we have to make it easy though or ex. expose it in the UI - but I think it's acceptable to allow it to work with `about:config`, as long as there aren't implications as previously stated)*. > Moreover, it's inappropriate to use webcompat as a whitelist. It's meant to fix bugs and incompatibilities with the default config, not gatekeep features. I don't understand what you're referring to here; the Web Compat page is meant to document websites with known issues/breakage, so that users are aware and can understand why something doesn't work *(and how they can fix/workaround it)*. It's not a whitelist or gatekeeping, perhaps you're referring to something else?

bugsbun commented

2025-05-09 22:40:20 +02:00

Author

So to confirm I understood you correctly (...)

Yes, you did. On 137, that is.

I don't understand what you're referring to here; the Web Compat page is meant to document websites with known issues/breakage

Ah, I thought you were patching about:compat type of exceptions yourself. What I meant is, if you were, then that list would implicitly become a whitelist since users would first have to submit a DRM website for you to unlock.

That doesn't mean we have to make it easy though or ex. expose

It's normal to hide an unsupported feature, but once activated it's preferable if you can manage it effectively. For instance, it would be better if it appeared - when activated - among the site settings of the exceptions list.

>So to confirm I understood you correctly (...) Yes, you did. On 137, that is. >I don't understand what you're referring to here; the Web Compat page is meant to document websites with known issues/breakage Ah, I thought you were patching about:compat type of exceptions yourself. What I meant is, if you were, then that list would implicitly become a whitelist since users would first have to submit a DRM website for you to unlock. >That doesn't mean we have to make it easy though or ex. expose It's normal to hide an unsupported feature, but once activated it's preferable if you can manage it effectively. For instance, it would be better if it appeared - when activated - among the site settings of the exceptions list.

👍 1

celenity commented

2025-05-10 00:29:20 +02:00

Owner

Ah, I thought you were patching about:compat type of exceptions yourself. What I meant is, if you were, then that list would implicitly become a whitelist since users would first have to submit a DRM website for you to unlock.

That makes sense. We do include overrides to fix breakage in certain instances (ex. we set FPP overrides and allow WebGL by default on sites known to have issues - but this isn't done through about:compat, and both of these examples are optional and users can disable our overrides/add their own), but we'd never do something like that for DRM.

It's normal to hide an unsupported feature, but once activated it's preferable if you can manage it effectively. For instance, it would be better if it appeared - when activated - among the site settings of the exceptions list.

This wouldn't really be possible unfortunately, Gecko prefs (ex. from the about:config) don't interact with the UI like they do on desktop. We could add a UI toggle though (probably in the Secret/Hidden settings section), but this would require a non-trivial amount of extra time and effort - and I don't think it's worth it to put time/effort into a feature that we don't support, never plan to support, and strongly oppose. There are plenty of other features we'd prioritize and rather focus on, but I do acknowledge this currently isn't ideal.

> Ah, I thought you were patching about:compat type of exceptions yourself. What I meant is, if you were, then that list would implicitly become a whitelist since users would first have to submit a DRM website for you to unlock. That makes sense. We do include overrides to fix breakage in certain instances *(ex. we set FPP overrides and allow WebGL by default on sites known to have issues - but this isn't done through `about:compat`, and both of these examples are optional and users can disable our overrides/add their own)*, but we'd never do something like that for DRM. > It's normal to hide an unsupported feature, but once activated it's preferable if you can manage it effectively. For instance, it would be better if it appeared - when activated - among the site settings of the exceptions list. This wouldn't really be possible unfortunately, Gecko prefs *(ex. from the `about:config`)* don't interact with the UI like they do on desktop. We could add a UI toggle though *(probably in the Secret/Hidden settings section)*, but this would require a non-trivial amount of extra time and effort - and I don't think it's worth it to put time/effort into a feature that we don't support, never plan to support, and strongly oppose. There are plenty of other features we'd prioritize and rather focus on, but I do acknowledge this currently isn't ideal.

GW72 commented

2025-05-10 07:05:39 +02:00

@celenity wrote in #108 (comment):

True, but I'm not convinced that's enough of a justification for us to enable/support a technology designed with the explicit intent and purpose to harm users (and one that includes the privacy and security concerns of DRM...).

@celenity wrote in #108 (comment):

It's not a whitelist or gatekeeping, perhaps you're referring to something else?

Semantics Sure, you can say "not convinced that's enough of a justification for us to enable/support a technology ", but DRM/Widvine are already available in Firefox, for when a user might want to use them. Allowing users to decide, doesn't equate to you "enabling it", it already is "enabled". You have not only "disabled it" but also, "disappeared it", removing the users' ability to decide how they want to use the product.

Like I said before, this is your project, but I start to wonder, do you, or do you not, want people to use Phoenix? Evaporating DRM/Widevine, could be part of the hardened version, right?

What's coming next? Perhaps Phoenix will completely disable Firefox's ability to connect to the internet because it is a feature using "a technology designed with the explicit intent and purpose to harm users"?

@celenity wrote in https://codeberg.org/celenity/Phoenix/issues/108#issuecomment-4423181: > True, but I'm not convinced that's enough of a justification for us to enable/support a technology designed with the explicit intent and purpose to harm users _(and one that includes the privacy and security concerns of DRM...)_. @celenity wrote in https://codeberg.org/celenity/Phoenix/issues/108#issuecomment-4423181: > It's not a whitelist or gatekeeping, perhaps you're referring to something else? **Semantics** Sure, you can say "not convinced that's enough of a justification for us to enable/support a technology ", but DRM/Widvine are **already** available in Firefox, for when a user might want to use them. Allowing users to decide, doesn't equate to you "enabling it", **it already is "enabled"**. You have not only "disabled it" but also, "disappeared it", removing the users' ability to decide how they want to use the product. Like I said before, this is your project, but I start to wonder, do you, or do you not, want people to use `Phoenix`? **Evaporating DRM/Widevine, could be part of the hardened version, right?** What's coming next? Perhaps `Phoenix` will completely disable Firefox's ability to connect to the internet because it is a feature using "a technology designed with the explicit intent and purpose to harm users"?

celenity commented

2025-05-10 17:50:59 +02:00

Owner

Semantics

I'm not really sure what you're referring to here; @bugsbun acknowledged it was a misunderstanding.

but DRM/Widvine are already available in Firefox, for when a user might want to use them. Allowing users to decide, doesn't equate to you "enabling it", it already is "enabled". You have not only "disabled it" but also, "disappeared it", removing the users' ability to decide how they want to use the product.

I disagree. As previously stated, there's nothing stopping users from re-enabling the relevant preferences in the about:config or otherwise - so I'm not sure how this is taking away the users' ability to decide to use it. We don't lock the related preferences (This issue's bug specifically is related to a patch we use on IronFox and prevents the preferences from working properly - which I do think is a problem and have an interest in addressing).

Based off your (and @bugsbun's feedback) though, I'll look and see if we can remove some of the DRM prefs to create less friction, but DRM will never be enabled by default or supported. I'm not trying to take away the choice or freedom of users though, so I do want this address this and will see what I can do.

> **Semantics** I'm not really sure what you're referring to here; @bugsbun acknowledged it was a misunderstanding. > but DRM/Widvine are **already** available in Firefox, for when a user might want to use them. Allowing users to decide, doesn't equate to you "enabling it", **it already is "enabled"**. You have not only "disabled it" but also, "disappeared it", removing the users' ability to decide how they want to use the product. I disagree. As previously stated, there's nothing stopping users from re-enabling the relevant preferences in the `about:config` or otherwise - so I'm not sure how this is taking away the users' ability to decide to use it. We don't lock the related preferences *(This issue's bug specifically is related to a patch we use on IronFox and prevents the preferences from working properly - which I do think is a problem and have an interest in addressing)*. Based off your *(and @bugsbun's feedback)* though, I'll look and see if we can remove some of the DRM prefs to create less friction, but DRM will **never** be enabled by default or supported. I'm not trying to take away the choice or freedom of users though, so I do want this address this and will see what I can do.

celenity referenced this issue from a commit

2025-05-11 09:17:54 +02:00

fix: Clean-up `gecko-liberate.patch` - https://codeberg.org/celenity/Phoenix/issues/108

celenity referenced this issue from a commit

2025-05-11 09:18:03 +02:00

Clean-up/re-organize and revise DRM prefs (+ add notes) - fixes https://codeberg.org/celenity/Phoenix/issues/108

celenity commented

2025-05-11 09:44:53 +02:00

Owner

FYI: Here's what I decided:

I reverted the recent change/patch in IronFox (So this bug is fixed for next release)
I went through and eliminated some of the unnecessary DRM prefs
I added notes that appear in the about:config to give context/information for users
I locked media.gmp-widevinecdm.enabled, media.gmp-widevinecdm.visible, media.gmp-widevinecdm-l1.enabled, & media.gmp-widevinecdm-l1.visibletofalseon **Android** *(as this is extremely broken... I'm amazed this worked + we disable GMP anyways, and locking these will help prevent confusion)* - I and added a note in theabout:configfor users to seemedia.mediadrm-widevinecdm.visible` instead. I didn't lock these prefs anywhere else to confirm.

So things still aren't perfect, but to confirm, here's where we're at:

On Android, setting media.eme.enabled & media.mediadrm-widevinecdm.visible to true should re-enable DRM and allow it to work. Nothing else is needed.
On Desktop, setting media.eme.enabled, media.gmp-provider.enabled, media.gmp-widevinecdm.enabled, & media.gmp-widevinecdm.visible to true should re-enable DRM and allow it to work in most cases.
Windows users may optionally also set media.eme.playready.enabled, media.gmp-widevinecdm-l1.enabled, & media.gmp-widevinecdm-l1.visible to true, though this shouldn't be strictly required/necessary.

and like I said, there are notes in the about:config that will appear when these preferences are searched for, so that'll at least be something to help guide users.

I know this still isn't perfect, but I think this is a reasonable solution for the time being.

FYI: Here's what I decided: * I reverted the recent change/patch in IronFox *(So this bug is fixed for next release)* * I went through and eliminated some of the unnecessary DRM prefs * I added notes that appear in the `about:config` to give context/information for users * I locked `media.gmp-widevinecdm.enabled`, `media.gmp-widevinecdm.visible, `media.gmp-widevinecdm-l1.enabled`, & `media.gmp-widevinecdm-l1.visible` to `false` on **Android** *(as this is extremely broken... I'm amazed this worked + we disable GMP anyways, and locking these will help prevent confusion)* - I and added a note in the `about:config` for users to see `media.mediadrm-widevinecdm.visible` instead. I didn't lock these prefs anywhere else to confirm. So things still aren't perfect, but to confirm, here's where we're at: * On **Android**, setting `media.eme.enabled` & `media.mediadrm-widevinecdm.visible` to `true` should re-enable DRM and allow it to work. Nothing else is needed. * On **Desktop**, setting `media.eme.enabled`, `media.gmp-provider.enabled`, `media.gmp-widevinecdm.enabled`, & `media.gmp-widevinecdm.visible` to `true` should re-enable DRM and allow it to work in most cases. * **Windows** users may *optionally* also set `media.eme.playready.enabled`, `media.gmp-widevinecdm-l1.enabled`, & `media.gmp-widevinecdm-l1.visible` to `true`, though this shouldn't be strictly required/necessary. and like I said, there are notes in the `about:config` that will appear when these preferences are searched for, so that'll at least be something to help guide users. I know this still isn't perfect, but I think this is a reasonable solution for the time being.

celenity closed this issue

2025-05-11 09:44:54 +02:00

celenity commented

2025-06-22 02:50:59 +02:00

Owner

FYI @bugsbun @GW72: After further research, testing, and consideration - I'm planning to make some changes to the EME and GMP prefs for next release. I'd really appreciate your thoughts and feedback on this. I think this will go a long way to remove friction and please both those who are strongly anti-DRM (admittedly, like myself...), and those who would like to use it for whatever reason (such as yourselves), without compromising the values of the project.

First, here's some background:

By default, when EME/DRM is enabled (via media.eme.enabled), Firefox will automatically enable any available/supported CDMs as well. While this is typically just Widevine in most cases, Widevine is not the only CDM Firefox supports. For instance, on Windows, Firefox also enables Microsoft PlayReady (in addition to Widevine). There have also been other supported CDMs in the past as well, like Adobe's.
I don't agree with this behavior though, as I believe it should be up to the user to decide which CDM(s) they would like to use, instead of the browser automatically deciding for them. I don't think enabling EME should mean "also enable all available/supported CDMs", like Mozilla seems to.
For instance, maybe I enable EME, and I'm comfortable using PlayReady, but not Widevine, or vice versa? Or maybe the streaming services I'd like to use support Widevine and not PlayReady, so why should I also enable PlayReady, or vice versa? Maybe the streaming services I'd like to use support both - in that case, I don't see a reason to have both CDMs enabled, why not just pick the one I prefer? Etc...
Firefox also includes an additional CDM on Desktop, Clear Key. Unlike the other CDMs though, Clear Key is always active, regardless of media.eme.enabled's value. While Clear Key isn't proprietary like Widevine/PlayReady/etc. are, it still implements basic content protection (such as preventing users from downloading videos). It also adds additional attack surface, and has previously had security vulnerabilities.... (For reference, Tor Browser disables Clear Key due to these concerns)
There's not really a pref or official mechanism to disable Clear Key on Firefox, but I managed to find a clever work-around. Unlike Desktop, Firefox on Android prompts users and requires permission on a per-site basis to use EME. To support this behavior, Mozilla added a pref to Gecko (media.eme.require-app-approval), which tells Firefox to block EME unless the user grants permission. This pref can also be used on Desktop, but as Desktop doesn't have support for the permission/UI like Android, it always acts as if the request was blocked, and it ends up blocking ALL DRM content, including Clear Key (unlike the standard media.eme.enabled pref, as noted above).

So now with this context in mind, here's the changes I'm making and the approach Phoenix will take for EME going forward:

media.eme.require-app-approval will be set to true by default for all platforms.
Additionally, EME itself will remain disabled by default on all platforms, via the standard pref (media.eme.enabled).
Once EME is enabled, the CDMs will remain disabled by default, due to the reasons described above, so that the user can decide which CDM(s) they would like to use. (For Widevine: media.gmp-widevinecdm.enabled on Desktop, media.mediadrm-widevinecdm.visible on Android - and for PlayReady on Windows: media.eme.playready.enabled)
media.gmp-widevinecdm.visible has been removed. media.eme.enabled already hides Widevine from the UI, so all this does is hide Widevine for users who enable EME... which doesn't make sense to me; if one enables EME, we should let them see available CDMs. This is likely what caused Widevine, as you described @GW72, to evaporate... Widevine should now show in the Plugins section of about:addons if media.eme.enabled is set to true (though the plug-in will be disabled by default, due to media.gmp-widevinecdm.enabled; you can now manage it from the UI)
Gecko Media Plugins (GMP) will remain disabled by default, but with media.gmp-manager.updateEnabled instead of media.gmp-provider.enabled. media.gmp-provider.enabled is essentially useless, it doesn't actually disable GMP any of its plug-ins, all it does AFAICT is hide installed plug-ins from about:addons :/. In combination with other prefs we set, media.gmp-manager.updateEnabled appears to effectively disable GMP and prevent it from downloading plug-ins.
GMP is required for Widevine on Desktop, so you MUST set media.gmp-manager.updateEnabled to true to continue receiving updates to the Widevine CDM on Desktop (even if you've already installed Widevine).

So basically, it comes down to this:

On Android, want to use EME? Set media.eme.enabled to true in your about:config, and then enable your desired CDM (Currently, only Widevine is supported on Android: media.mediadrm-widevinecdm.visible).
On Desktop, want to use EME, but ONLY with FOSS CDMs (Currently this is just Clear Key)? Set media.eme.require-app-approval to false.
On Desktop, want to use EME with Widevine (in addition to Clear Key)? Set media.eme.require-app-approval to false, and set media.gmp-manager.updateEnabled & media.eme.enabled to true. You can then enable Widevine from the Plugins section of about:addons, or by setting media.gmp-widevinecdm.enabled to true.
On Windows, want to use EME with PlayReady (in addition to Clear Key)? Set media.eme.require-app-approval to false, and set media.eme.enabled & media.eme.playready.enabled to true.
On Windows, want to use EME with Widevine and PlayReady (in addition to Clear Key)? Set media.eme.require-app-approval to false, and set media.gmp-manager.updateEnabled, media.eme.enabled & media.eme.playready.enabled to true. You can then enable Widevine from the Plugins section of about:addons, or by setting media.gmp-widevinecdm.enabled to true.

The main thing left to figure out will be what to do for IronFox. I'm interested in pursuing a way to support the EME UI (so that sites require permission if EME is enabled), maybe behind a hidden setting; as long as it's not a burden on maintenance (since we still don't and will never officially support EME).

Overall, I'm really curious to hear thoughts on this. EME/DRM will still never be officially supported or recommended; (And I'd still strongly encourage you to complain to websites implementing EME for going out of their way to not support Phoenix/IronFox/etc...), but at the end of the day, I would much rather those insistent on enabling EME to use it with Phoenix or IronFox, instead of in a far less private and secure browser/environment, or a separate app where they have less control. (FWIW: I'd recommend using a separate browser profile for EME if you enable it). So I'm willing to attempt to make an effort to accommodate for this use case, as long as it's never enabled by default or promoted, and doesn't compromise privacy, security, and/or freedom for users who don't enable it.

FYI @bugsbun @GW72: After further research, testing, and consideration - I'm planning to make some changes to the EME and GMP prefs for next release. I'd really appreciate your thoughts and feedback on this. I think this will go a long way to remove friction and please both those who are strongly anti-DRM *(admittedly, like myself...)*, and those who would like to use it for whatever reason *(such as yourselves)*, without compromising the values of the project. First, here's some background: - By default, when EME/DRM is enabled (via `media.eme.enabled`), Firefox will automatically enable any available/supported CDMs as well. While this is typically just Widevine in most cases, Widevine is *not* the only CDM Firefox supports. For instance, on Windows, Firefox *also* enables Microsoft PlayReady *(in addition to Widevine)*. There have also been other supported CDMs in the past as well, like Adobe's. - I don't agree with this behavior though, as I believe it should be up to the user to decide which CDM(s) they would like to use, instead of the browser automatically deciding for them. I don't think enabling EME should mean "also enable all available/supported CDMs", like Mozilla seems to. - For instance, maybe I enable EME, and I'm comfortable using PlayReady, but not Widevine, or vice versa? Or maybe the streaming services I'd like to use support Widevine and not PlayReady, so why should I also enable PlayReady, or vice versa? Maybe the streaming services I'd like to use support **both** - in that case, I don't see a reason to have both CDMs enabled, why not just pick the one I prefer? Etc... - Firefox also includes an *additional* CDM on **Desktop**, [Clear Key](https://www.w3.org/TR/encrypted-media-2/#clear-key). Unlike the other CDMs though, Clear Key is **always** active, regardless of `media.eme.enabled`'s value. While Clear Key isn't proprietary like Widevine/PlayReady/etc. are, [it still implements basic content protection](https://bugzilla.mozilla.org/show_bug.cgi?id=1136707#c18) *(such as preventing users from downloading videos)*. It also adds additional attack surface, and [has previously had security vulnerabilities...](https://www.mozilla.org/security/advisories/mfsa2016-77/). *(For reference, Tor Browser disables Clear Key due to these concerns)* - There's not really a pref or official mechanism to disable Clear Key on Firefox, but I managed to find a clever work-around. Unlike Desktop, Firefox on Android prompts users and requires permission on a per-site basis to use EME. To support this behavior, Mozilla added a pref to Gecko *(`media.eme.require-app-approval`)*, which tells Firefox to block EME unless the user grants permission. This pref can also be used on Desktop, but as Desktop doesn't have support for the permission/UI like Android, it always acts as if the request was blocked, and it ends up blocking **ALL** DRM content, **including Clear Key** *(unlike the standard `media.eme.enabled` pref, as noted above)*. So now with this context in mind, here's the changes I'm making and the approach Phoenix will take for EME going forward: - `media.eme.require-app-approval` will be set to `true` by default for all platforms. - Additionally, EME itself will remain disabled by default on all platforms, via the standard pref (`media.eme.enabled`). - Once EME is enabled, the CDMs will remain disabled by default, due to the reasons described above, so that the user can decide which CDM(s) they would like to use. *(For **Widevine**: `media.gmp-widevinecdm.enabled` on Desktop, `media.mediadrm-widevinecdm.visible` on Android - and for **PlayReady** on Windows: `media.eme.playready.enabled`)* - `media.gmp-widevinecdm.visible` has been removed. `media.eme.enabled` already hides Widevine from the UI, so all this does is hide Widevine for users who enable EME... which doesn't make sense to me; if one enables EME, we should let them see available CDMs. This is likely what caused Widevine, as you described @GW72, to `evaporate`... Widevine should now show in the `Plugins` section of [`about:addons`](about:addons) if `media.eme.enabled` is set to `true` *(though the plug-in will be disabled by default, due to `media.gmp-widevinecdm.enabled`; you can now manage it from the UI)* - Gecko Media Plugins (GMP) will remain disabled by default, but with `media.gmp-manager.updateEnabled` **instead** of `media.gmp-provider.enabled`. `media.gmp-provider.enabled` is essentially useless, it doesn't actually disable GMP any of its plug-ins, all it does AFAICT is hide installed plug-ins from `about:addons` :/. In combination with other prefs we set, `media.gmp-manager.updateEnabled` appears to effectively disable GMP and prevent it from downloading plug-ins. - GMP is required for **Widevine** on **Desktop**, so you **MUST** set `media.gmp-manager.updateEnabled` to `true` to continue receiving updates to the Widevine CDM on Desktop *(even if you've already installed Widevine)*. So basically, it comes down to this: - On Android, want to use EME? Set `media.eme.enabled` to `true` in your `about:config`, and then enable your desired CDM (Currently, **only** Widevine is supported on Android: `media.mediadrm-widevinecdm.visible`). - On Desktop, want to use EME, but **ONLY** with **FOSS** CDMs *(Currently this is just Clear Key)*? Set `media.eme.require-app-approval` to `false`. - On Desktop, want to use EME with Widevine *(in addition to Clear Key)*? Set `media.eme.require-app-approval` to `false`, and set `media.gmp-manager.updateEnabled` & `media.eme.enabled` to `true`. You can then enable Widevine from the `Plugins` section of [`about:addons`](about:addons), **or** by setting `media.gmp-widevinecdm.enabled` to `true`. - On **Windows**, want to use EME with PlayReady *(in addition to Clear Key)*? Set `media.eme.require-app-approval` to `false`, and set `media.eme.enabled` & `media.eme.playready.enabled` to `true`. - On **Windows**, want to use EME with Widevine **and** PlayReady *(in addition to Clear Key)*? Set `media.eme.require-app-approval` to `false`, and set `media.gmp-manager.updateEnabled`, `media.eme.enabled` & `media.eme.playready.enabled` to `true`. You can then enable Widevine from the `Plugins` section of [`about:addons`](about:addons), **or** by setting `media.gmp-widevinecdm.enabled` to `true`. The main thing left to figure out will be what to do for IronFox. I'm interested in pursuing a way to support the EME UI *(so that sites require permission if EME is enabled)*, maybe behind a hidden setting; as long as it's not a burden on maintenance *(since we still don't and will never officially support EME)*. Overall, I'm really curious to hear thoughts on this. EME/DRM will still **never** be officially supported or recommended; *(And I'd still strongly encourage you to complain to websites implementing EME for going out of their way to not support Phoenix/IronFox/etc...)*, but at the end of the day, I would much rather those insistent on enabling EME to use it with Phoenix or IronFox, instead of in a far less private and secure browser/environment, or a separate app where they have less control. *(FWIW: I'd recommend using a separate browser profile for EME if you enable it)*. So I'm willing to *attempt* to make an effort to accommodate for this use case, as long as it's never enabled by default or promoted, and doesn't compromise privacy, security, and/or freedom for users who don't enable it.

👍 1

GW72 commented

2025-06-25 05:21:17 +02:00

A bit late but it wasn't possible to get to this until now (not that it matters much of course!!). So, this all sounds fine and basically addresses what I was trying to say all along. Specifically this:

@celenity wrote in #108 (comment):

but at the end of the day, I would much rather those insistent on enabling EME to use it with Phoenix or IronFox, instead of in a far less private and secure browser/environment, or a separate app where they have less control

This was the point for me, exactly this. So many times in the past, with other projects, I had to abandon because it got too complicated to white-list or work around. The instructions/descriptions above, while lengthy, are likely complete and will actually allow a user to make adjustments to the necessary prefs AND continue to use Phoenix.

And for the record, I don't actually need or use DRM in Firefox! But I made the point, which yes, did unfortunately cause some tension, because I know so many others will just give up using Phoenix because many will have no idea why something isn't working for their usage case, they will likely not put much effort into finding solutions and will then just abandon Phoenix, which would be a real shame.

And that's because @celenity's expertise and implementation, care for the project and ambition to succeed, should be celebrated! Phoenix just works, and I for one, who has tried so many other privacy implementations experience no real (abandon inducing) breakage. And these forum/issues are actually fit for purpose where serious attention is given to whatever user case problems are experienced. That is also quite rare, and I for one, do hope the ease of speaking up AND being heard will continue.

So apologies for tensions created but it was more of a means to and end than any kind of personal issue. I always thought the more accommodations/flexibility that can be made for a given user case, the better. Otherwise as seems to now be understood, users will simply go to something less safe/private, and that would be a shame.

So, thanks again for time and attention spent on this. It is greatly appreciated and IMHO, only serves to make your Phoenix project stronger.

A bit late but it wasn't possible to get to this until now (not that it matters much of course!!). So, this all sounds fine and basically addresses what I was trying to say all along. Specifically this: @celenity wrote in https://codeberg.org/celenity/Phoenix/issues/108#issuecomment-5522324: > but at the end of the day, I would much rather those insistent on enabling EME to use it with Phoenix or IronFox, instead of in a far less private and secure browser/environment, or a separate app where they have less control This was the point for me, exactly this. So many times in the past, with other projects, I had to abandon because it got too complicated to white-list or work around. The instructions/descriptions above, while lengthy, are likely complete and will actually allow a user to make adjustments to the necessary `prefs ` AND continue to use `Phoenix`. And for the record, I don't actually need or use `DRM` in `Firefox`! But I made the point, which yes, did unfortunately cause some tension, because I know so many others will just give up using Phoenix because many will have no idea why something isn't working for their usage case, they will likely not put much effort into finding solutions and will then just abandon `Phoenix`, which would be a real shame. And that's because @celenity's expertise and implementation, care for the project and ambition to succeed, should be celebrated! `Phoenix` just works, and I for one, who has tried so many other privacy implementations experience no real (abandon inducing) breakage. And these forum/issues are actually fit for purpose where serious attention is given to whatever user case problems are experienced. That is also quite rare, and I for one, do hope the ease of speaking up AND being heard will continue. So apologies for tensions created but it was more of a means to and end than any kind of personal issue. I always thought the more accommodations/flexibility that can be made for a given user case, the better. Otherwise as seems to now be understood, users will simply go to something less safe/private, and that would be a shame. So, thanks again for time and attention spent on this. It is greatly appreciated and IMHO, only serves to make your Phoenix project stronger.

👍 1 ❤️ 1 🚀 1

celenity commented

2025-07-10 00:03:25 +02:00

Owner

So FYI @bugsbun @GW72, for the next IronFox release, I added new hidden/secret settings to control EME and Widevine.

The settings function as follows:

Enable Encrypted Media Extensions (EME) - When enabled, this sets media.eme.enabled to true, and it exposes the UI for controlling the DRM site permission.
Enable Widevine CDM - This depends on the Enable Encrypted Media Extensions (EME) setting. When enabled, it sets media.mediadrm-widevinecdm.visible to true.

This should allow users to re-enable EME if desired at their own risk (still NOT supported or recommended...), while allowing control of which sites can and can't use it with the DRM permission, like vanilla Firefox allows.

So FYI @bugsbun @GW72, for the next IronFox release, I [added new hidden/secret settings to control EME and Widevine](https://gitlab.com/ironfox-oss/IronFox/-/commit/346608f702ae7cdc873725030f1bc1c4f4796430). The settings function as follows: - `Enable Encrypted Media Extensions (EME)` - When enabled, this sets `media.eme.enabled` to true, and it exposes the UI for controlling the DRM site permission. - `Enable Widevine CDM` - This depends on the `Enable Encrypted Media Extensions (EME)` setting. When enabled, it sets `media.mediadrm-widevinecdm.visible` to `true`. This should allow users to re-enable EME if desired at their own risk *(still NOT supported or recommended...)*, while allowing control of which sites can and can't use it with the DRM permission, like vanilla Firefox allows.