Use Phoenix as a base for LibreWolf #2823

any1here commented 2026年01月23日 12:55:56 +01:00

Your Question

I suggest we use Phoenix as the base for our settings, since it’s a high-quality list that includes many small improvements we would otherwise miss.

This continues the discussion which ended here librewolf/settings#107 (comment)

### Your Question I suggest we use [Phoenix](https://codeberg.org/celenity/Phoenix) as the base for our settings, since it’s a high-quality list that includes many small improvements we would otherwise miss. This continues the discussion which ended here https://codeberg.org/librewolf/settings/pulls/107#issuecomment-10102812

sarge commented 2026年01月25日 14:12:32 +01:00

Thoughts from user and downstream perspectives:

I hope that in this process, each pref will still be considered individually? Considering both ensuring quality and minimizing breaking for users.

Imagining a one-time process like

1. Diff snapshots of librewolf.cfg with phoenix prefs and decide what do to about diffs
2. Commit diffs decided on (preferably in smaller chunks and over time)

Then Ongoing: Merge in new changes from Phoenix in some fashion on some schedule

If it's decided to also reformat/reorder librewolf.cfg to more closely match the Phoenix one in order to make working with diffs smoother, then I guess that can happen at any point, but importantly for us: separately. But maybe not worth it?

I think it makes sense for LibreWolf to consider pulling in changes from either/or Phoenix, Arkenfox (and maybe others) if it makes sense for the change in question. It's diverged enough from upstream and has enough going around it (that's a good thing!) to be consider its own unit and be treated respectfully as such IMO.

Thoughts from user and downstream perspectives: I hope that in this process, each pref will still be considered individually? Considering both ensuring quality and minimizing breaking for users. Imagining a one-time process like 1. Diff snapshots of librewolf.cfg with phoenix prefs and decide what do to about diffs 2. Commit diffs decided on (preferably in smaller chunks and over time) Then Ongoing: Merge in new changes from Phoenix in some fashion on some schedule _If_ it's decided to also reformat/reorder librewolf.cfg to more closely match the Phoenix one in order to make working with diffs smoother, then I guess that can happen at any point, but importantly for us: separately. But maybe not worth it? I think it makes sense for LibreWolf to consider pulling in changes from either/or Phoenix, Arkenfox (and maybe others) if it makes sense for the change in question. It's diverged enough from upstream and has enough going around it (that's a good thing!) to be consider its own unit and be treated respectfully as such IMO.

alyx161 commented 2026年01月25日 14:27:20 +01:00

As mentioned before, I share the same opinion.
The general idea of taking inspiration from Phoenix is good. I also would not mind moving to a similar format to make tracking changes easier.

However, I still think each change should be evaluated and discussed individually.
Phoenix has loads of settings that we have never touched. Just stuffing them all into a PR based on a rough "that looks about right" would be an absolute deal breaker for me.

If we want to introduce a change, it should happen because we want that specific change.

As mentioned before, I share the same opinion. The general idea of taking inspiration from Phoenix is good. I also would not mind moving to a similar format to make tracking changes easier. However, I still think each change should be evaluated and discussed individually. Phoenix has loads of settings that we have never touched. Just stuffing them all into a PR based on a rough "that looks about right" would be an absolute deal breaker for me. If we want to introduce a change, it should happen because we want that specific change.

sarge commented 2026年01月25日 14:40:29 +01:00

That's reassuring @alyx161 !

I would have concerns about straight up rebasing on Phoenix or resetting on a snapshot of it. My view is that they are a bit more "enthusiast modpack" made by and for people who want to tweak every single knob because they can and inject their personal highly opinionated adjustments here and there. A whole zoo of random custom third-party lists for uBO is one example. Now I don't think enthusiast modpacks are bad or that this has to be such a concern for such a project like Phoenix. And I think the work they do benefit the whole ecosystem by experimenting at scale, showing what's possible and introducing a new generation to tinkering and browser customization.

But that's not what I expect from a security-focused browser like LW. I expect it to be safe, reliable, lean and predictable. I think this is why many users choose LW. And people can still go yolo on it if they decide to.

That's reassuring @alyx161 ! I would have concerns about straight up rebasing on Phoenix or resetting on a snapshot of it. My view is that they are a bit more "enthusiast modpack" made by and for people who want to tweak [every single knob](https://codeberg.org/celenity/Phoenix/wiki/Features) because they can and inject their personal highly opinionated adjustments here and there. A whole zoo of random custom third-party lists for uBO is one example. Now I don't think enthusiast modpacks are bad or that this has to be such a concern for such a project like Phoenix. And I think the work they do benefit the whole ecosystem by experimenting at scale, showing what's possible and introducing a new generation to tinkering and browser customization. But that's not what I expect from a security-focused browser like LW. I expect it to be safe, reliable, lean and predictable. I think this is why many users choose LW. And people can still go yolo on it if they decide to.

any1here commented 2026年01月25日 15:25:55 +01:00

@Sarge
I personally reviewed the entire https://codeberg.org/celenity/Phoenix/src/branch/dev/build/phoenix-unified.js. Most changes either produce no noticeable user-facing differences or fit well with what we currently provide.

I wouldn't call Phoenix an "enthusiast modpack" since it is a highly researched list and not just some randomly diced together project. Celenity definitely knows what they are doing and has a better understanding around Firefox than I do.

@Celenity would like to have your opinion on this, if you don't mind.

@Sarge I personally reviewed the entire https://codeberg.org/celenity/Phoenix/src/branch/dev/build/phoenix-unified.js. Most changes either produce no noticeable user-facing differences or fit well with what we currently provide. I wouldn't call Phoenix an "enthusiast modpack" since it is a highly researched list and not just some randomly diced together project. Celenity definitely knows what they are doing and has a better understanding around Firefox than I do. @Celenity would like to have your opinion on this, if you don't mind.

sarge commented 2026年01月25日 23:03:44 +01:00

Off topicish

I personally reviewed the entire https://codeberg.org/celenity/Phoenix/src/branch/dev/build/phoenix-unified.js

Respectfully,

Was that reviewed with the same care as each of these recent commit to LW main branch?

https://codeberg.org/librewolf/source/commits/branch/main/Makefile

it is a highly researched list and not just some randomly diced together project. Celenity definitely knows what they are doing and has a better understanding around Firefox than I do.

Not saying anything else but I also think it's besides the point.

<details><summary>Off topicish</summary> > I personally reviewed the entire https://codeberg.org/celenity/Phoenix/src/branch/dev/build/phoenix-unified.js Respectfully, Was that reviewed with the same care as each of these recent commit to LW main branch? <img src="https://codeberg.org/attachments/405c80c0-1d47-48bb-b40e-ad702ac8701b" /> https://codeberg.org/librewolf/source/commits/branch/main/Makefile </details> > it is a highly researched list and not just some randomly diced together project. Celenity definitely knows what they are doing and has a better understanding around Firefox than I do. Not saying anything else but I also think it's besides the point.

alyx161 commented 2026年01月25日 23:10:19 +01:00

@Sarge wrote in #2823 (comment):

Respectfully,

Was that reviewed with the same care as these recent commit to LW main branch?

Probably doesn't help to get too personal here.
In that case he was just trying to address an issue with the new CI. It was the first run on the new infra, which is not that easy to test locally.

@Sarge wrote in #2823 (comment):

Not arguing with any of that but I also think it's besides the point.

Yea, I don't think anyone would argue that Phoenix itself is a bad project.
And as mentioned before, I don't think its a bad idea to look at Phoenix when it comes to changes at LibreWolf.

I just think changes should be evaluated individually and honestly over a reasonable time-frame too.
Reviewing 1k changes is not something you do in a evening, or a single PR.

@Sarge wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10158558: > Respectfully, > > Was that reviewed with the same care as these recent commit to LW main branch? Probably doesn't help to get too personal here. In that case he was just trying to address an issue with the new CI. It was the first run on the new infra, which is not that easy to test locally. @Sarge wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10158558: > Not arguing with any of that but I also think it's besides the point. Yea, I don't think anyone would argue that Phoenix itself is a bad project. And as mentioned before, I don't think its a bad idea to look at Phoenix when it comes to changes at LibreWolf. I just think changes should be evaluated individually and honestly over a reasonable time-frame too. Reviewing 1k changes is not something you do in a evening, or a single PR.

jj17 commented 2026年01月26日 10:45:42 +01:00

From a Browser that promises privacy and security I would expect that they check the settings they provide, and don't just copy the settings from someone else.

Hope alyx161 is right that they get really checked properly

From a Browser that promises privacy and security I would expect that they check the settings they provide, and don't just copy the settings from someone else. Hope alyx161 is right that they get really checked properly

any1here commented 2026年01月26日 11:25:17 +01:00

@sarge wrote in #2823 (comment):

Respectfully,

Was that reviewed with the same care as each of these recent commit to LW main branch?

Did not know that testing Makefile changes has a noticeable impact on end users 😄

@sarge wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10158558: > Respectfully, > > Was that reviewed with the same care as each of these recent commit to LW main branch? Did not know that testing Makefile changes has a noticeable impact on end users 😄

sarge commented 2026年01月30日 22:48:54 +01:00

@any1here wrote in #2823 (comment):

@sarge wrote in #2823 (comment):

Respectfully,
Was that reviewed with the same care as each of these recent commit to LW main branch?

Did not know that testing Makefile changes has a noticeable impact on end users 😄

For users who build from source it does. I hope this is still supported?

Besides, when you're basically saying "I looked it over, it's fine, trust me" it irks me a bit right after having seen what looks to like me to playing fast and loose with a publicly trusted signing key. It looks like one typo away and someone triggering the build runner from leaking something sensitive to stderr or stdout in CI logs. Maybe it's low-probability risk but given how high-impact it would be I'm TBH concerned to be so dismissive of it when brought up. There might be low-probability but significant risks involved in bulk updates of the userprefs, too.

librewolf/source@0c8f81b311

librewolf/source@ee4d83f086

I've done series of much uglier and hackier commits than that when working on CI. No shame in that. But not when they've had access to such signing secrets with such established public trust. I'd test it on a different branch or fork that doesn't have access to the prod secret first.

I wouldn't bring this up here if the last follow-up hadn't been so cavalier.. Had it been a year ago it'd be water under the bridge. Maybe things will come off much differently after a longer period of stability in project operationals? Or lower rate of change in Phoenix? Sometimes there's higher level meaning in deferring change just for the sake of letting things settle. Making one major change at a time and letting things breathe in between. Also makes it easier to understand what changes had what impact in hindsight down the road. High and low.

---

Separately, consider the Phoenix perspective. I obv can't speak on behalf of maintainer but it seems to me that they are already confident and conscious about they way they maintain the project. There is a clear tension between that and LW requirements (again, not an indictment of Phoenix or saying they it'd be better if they changed their ways. Just different priorities). So for LW to base on Phoenix without concerns would, I think, imply that Phoenix is now restricted in the things they do in each update and how they roll things out. I think that might hold Phoenix back and restrict and slow down their releases because they consider the impact on LibreWolf. They wouldn't burn as brightly. And not because they'd be forced to but because they care and might feel responsible. It might become a burden or stress for the maintainers even with best intentions. And as a result, it would not be as different from LW and therefore not as useful for inspiration and borrowing ideas. If some site breaks in a confusing way in either Phoenix or LW today, having the other as a reference to diff with is nice. When 99% of the config is the same it usually means they behave the same and one less reference point.

LW users who prefer the full-on Phoenix experience can still just, like, use Phoenix with LW. Also IronFox is a Phoenix-based FF fork with same maintainer as Phoenix that exists.

@any1here wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10170903: > @sarge wrote in #2823 (comment): > > > Respectfully, > > Was that reviewed with the same care as each of these recent commit to LW main branch? > > Did not know that testing Makefile changes has a noticeable impact on end users :smile: For users who [build from source](https://codeberg.org/librewolf/source/#building-with-this-repository) it does. I hope this is still supported? Besides, when you're basically saying "I looked it over, it's fine, trust me" it irks me a bit right after having seen what looks to like me to playing fast and loose with a publicly trusted signing key. It looks like one typo away and someone triggering the build runner from leaking something sensitive to stderr or stdout in CI logs. Maybe it's low-probability risk but given how high-impact it would be I'm TBH concerned to be so dismissive of it when brought up. There might be low-probability but significant risks involved in bulk updates of the userprefs, too. https://codeberg.org/librewolf/source/commit/0c8f81b311404f7597eaf6f8c07b1d18d4231414 https://codeberg.org/librewolf/source/commit/ee4d83f086691bd90d46524f69e93509a0e733f4 I've done series of much uglier and hackier commits than that when working on CI. No shame in that. But not when they've had access to such signing secrets with such established public trust. I'd test it on a different branch or fork that doesn't have access to the prod secret first. I wouldn't bring this up here if the last follow-up hadn't been so cavalier.. Had it been a year ago it'd be water under the bridge. Maybe things will come off much differently after a longer period of stability in project operationals? Or lower rate of change in Phoenix? Sometimes there's higher level meaning in deferring change just for the sake of letting things settle. Making one major change at a time and letting things breathe in between. Also makes it easier to understand what changes had what impact in hindsight down the road. High and low. --- Separately, consider the Phoenix perspective. I obv can't speak on behalf of maintainer but it seems to me that they are already confident and conscious about they way they maintain the project. There is a clear tension between that and LW requirements (again, not an indictment of Phoenix or saying they it'd be better if they changed their ways. Just different priorities). So for LW to base on Phoenix without concerns would, I think, imply that Phoenix is now restricted in the things they do in each update and how they roll things out. I think that might hold Phoenix back and restrict and slow down their releases because they consider the impact on LibreWolf. They wouldn't burn as brightly. And not because they'd be forced to but because they care and might feel responsible. It might become a burden or stress for the maintainers even with best intentions. And as a result, it would not be as different from LW and therefore not as useful for inspiration and borrowing ideas. If some site breaks in a confusing way in either Phoenix or LW today, having the other as a reference to diff with is nice. When 99% of the config is the same it usually means they behave the same and one less reference point. LW users who prefer the full-on Phoenix experience can still just, like, use Phoenix with LW. Also IronFox is a Phoenix-based FF fork with same maintainer as Phoenix that exists.

any1here commented 2026年01月31日 15:20:50 +01:00

@sarge wrote in #2823 (comment):

For users who build from source it does. I hope this is still supported?

I doubt anyone was impacted by me changing an already-broken functionality in the Makefile, which most likely nobody outside of us is even using.

@sarge wrote in #2823 (comment):

Besides, when you're basically saying "I looked it over, it's fine, trust me" it irks me a bit right after having seen what looks to like me to playing fast and loose with a publicly trusted signing key. It looks like one typo away and someone triggering the build runner from leaking something sensitive to stderr or stdout in CI logs. Maybe it's low-probability risk but given how high-impact it would be I'm TBH concerned to be so dismissive of it when brought up. There might be low-probability but significant risks involved in bulk updates of the userprefs, too.

librewolf/source@0c8f81b311

librewolf/source@ee4d83f086

I've done series of much uglier and hackier commits than that when working on CI. No shame in that. But not when they've had access to such signing secrets with such established public trust. I'd test it on a different branch or fork that doesn't have access to the prod secret first.

I wouldn't bring this up here if the last follow-up hadn't been so cavalier.. Had it been a year ago it'd be water under the bridge. Maybe things will come off much differently after a longer period of stability in project operationals? Or lower rate of change in Phoenix? Sometimes there's higher level meaning in deferring change just for the sake of letting things settle. Making one major change at a time and letting things breathe in between. Also makes it easier to understand what changes had what impact in hindsight down the road. High and low.

Why do you keep bringing up Makefile changes when the topic is Phoenix? How do these even compare? Are you just trying to prove a point and question my knowledge by bringing in things that don't share a similar knowledge base?

@sarge wrote in #2823 (comment):

Separately, consider the Phoenix perspective. I obv can't speak on behalf of maintainer but it seems to me that they are already confident and conscious about they way they maintain the project. There is a clear tension between that and LW requirements (again, not an indictment of Phoenix or saying they it'd be better if they changed their ways. Just different priorities). So for LW to base on Phoenix without concerns would, I think, imply that Phoenix is now restricted in the things they do in each update and how they roll things out. I think that might hold Phoenix back and restrict and slow down their releases because they consider the impact on LibreWolf. They wouldn't burn as brightly. And not because they'd be forced to but because they care and might feel responsible. It might become a burden or stress for the maintainers even with best intentions. And as a result, it would not be as different from LW and therefore not as useful for inspiration and borrowing ideas. If some site breaks in a confusing way in either Phoenix or LW today, having the other as a reference to diff with is nice. When 99% of the config is the same it usually means they behave the same and one less reference point.

This is a non-issue since Celenity is in favor of us adopting Phoenix.

So the TL;DR of your post basically is that having made questionable Makefile edits undermines my ability to recommend what Firefox settings we should use.

@sarge wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10268128: > For users who [build from source](https://codeberg.org/librewolf/source/#building-with-this-repository) it does. I hope this is still supported? I doubt anyone was impacted by me changing an already-broken functionality in the Makefile, which most likely nobody outside of us is even using. @sarge wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10268128: > Besides, when you're basically saying "I looked it over, it's fine, trust me" it irks me a bit right after having seen what looks to like me to playing fast and loose with a publicly trusted signing key. It looks like one typo away and someone triggering the build runner from leaking something sensitive to stderr or stdout in CI logs. Maybe it's low-probability risk but given how high-impact it would be I'm TBH concerned to be so dismissive of it when brought up. There might be low-probability but significant risks involved in bulk updates of the userprefs, too. > > [`librewolf/source@0c8f81b311`](https://codeberg.org/librewolf/source/commit/0c8f81b311404f7597eaf6f8c07b1d18d4231414) > > [`librewolf/source@ee4d83f086`](https://codeberg.org/librewolf/source/commit/ee4d83f086691bd90d46524f69e93509a0e733f4) > > I've done series of much uglier and hackier commits than that when working on CI. No shame in that. But not when they've had access to such signing secrets with such established public trust. I'd test it on a different branch or fork that doesn't have access to the prod secret first. > > I wouldn't bring this up here if the last follow-up hadn't been so cavalier.. Had it been a year ago it'd be water under the bridge. Maybe things will come off much differently after a longer period of stability in project operationals? Or lower rate of change in Phoenix? Sometimes there's higher level meaning in deferring change just for the sake of letting things settle. Making one major change at a time and letting things breathe in between. Also makes it easier to understand what changes had what impact in hindsight down the road. High and low. Why do you keep bringing up Makefile changes when the topic is Phoenix? How do these even compare? Are you just trying to prove a point and question my knowledge by bringing in things that don't share a similar knowledge base? @sarge wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-10268128: > Separately, consider the Phoenix perspective. I obv can't speak on behalf of maintainer but it seems to me that they are already confident and conscious about they way they maintain the project. There is a clear tension between that and LW requirements (again, not an indictment of Phoenix or saying they it'd be better if they changed their ways. Just different priorities). So for LW to base on Phoenix without concerns would, I think, imply that Phoenix is now restricted in the things they do in each update and how they roll things out. I think that might hold Phoenix back and restrict and slow down their releases because they consider the impact on LibreWolf. They wouldn't burn as brightly. And not because they'd be forced to but because they care and might feel responsible. It might become a burden or stress for the maintainers even with best intentions. And as a result, it would not be as different from LW and therefore not as useful for inspiration and borrowing ideas. If some site breaks in a confusing way in either Phoenix or LW today, having the other as a reference to diff with is nice. When 99% of the config is the same it usually means they behave the same and one less reference point. This is a non-issue since Celenity is in favor of us adopting Phoenix. So the TL;DR of your post basically is that having made questionable Makefile edits undermines my ability to recommend what Firefox settings we should use.

DotaFSS commented 2026年02月08日 12:06:43 +01:00

Please set all settings to the strictest defaults to ensure maximum security and privacy and e,c,t,

Please set all settings to the strictest defaults to ensure maximum security and privacy and e,c,t,

MahoganyPrime commented 2026年05月23日 05:28:46 +02:00

As an end-user, I would love to see LibreWolf adopt Phoenix hardening approach, as it allows for a more flexible/elegant approach to hardening than the more stricter/rigid ways of Ankerfox. Phoenix would allow LibreWolf to be more flexible without sacrificing hardening.

LibreWolf could fill in the gap for windows users who want the superb hardening and flexibility of FF+Phoenix without having to move files every time there is an update.

One factor LibreWolf would stand out over FF+Phoenix would be allowing DRM for those who need it. You guys already do this and this would benefit users who again, want the hardening and flexibility of Phoenix and still be able to watch YouTube videos.

As an end-user, I would love to see LibreWolf adopt Phoenix hardening approach, as it allows for a more flexible/elegant approach to hardening than the more stricter/rigid ways of Ankerfox. Phoenix would allow LibreWolf to be more flexible without sacrificing hardening. LibreWolf could fill in the gap for windows users who want the superb hardening and flexibility of FF+Phoenix without having to move files every time there is an update. One factor LibreWolf would stand out over FF+Phoenix would be allowing DRM for those who need it. You guys already do this and this would benefit users who again, want the hardening and flexibility of Phoenix and still be able to watch YouTube videos.

celenity commented 2026年05月23日 05:45:13 +02:00

@MahoganyPrime wrote in #2823 (comment):

One factor LibreWolf would stand out over FF+Phoenix would be allowing DRM for those who need it. You guys already do this and this would benefit users who again, want the hardening and flexibility of Phoenix and still be able to watch YouTube videos.

FWIW, it is technically possible to enable EME with FF+Phoenix, ATM I believe the prefs you’d need to override/manually set for desktop are:

• browser.eme.ui.enabled -> true
• media.eme.enabled -> true
• media.eme.require-app-approval -> false
• media.eme.require-app-approval.prompt.testing -> false

You’d then need to enable a CDM as well. For Widevine on desktop, you’d want to set:

• media.gmp-manager.updateEnabled -> true
• media.gmp-widevinecdm.enabled -> true

I considered adding a Phoenix-specific preference to streamline/make this easier to control, but I decided against it (because A: I’d like to keep Phoenix-specific preferences to a minimum and B: it’s not something we officially support or recommend).

So, in theory, LibreWolf could just override these preferences and/or add ex. UI toggles to control them.

@MahoganyPrime wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-15699578: > One factor LibreWolf would stand out over FF+Phoenix would be allowing DRM for those who need it. You guys already do this and this would benefit users who again, want the hardening and flexibility of Phoenix and still be able to watch YouTube videos. FWIW, it is *technically* possible to enable EME with FF+Phoenix, ATM I believe the prefs you’d need to override/manually set for desktop are: - `browser.eme.ui.enabled` -> `true` - `media.eme.enabled` -> `true` - `media.eme.require-app-approval` -> `false` - `media.eme.require-app-approval.prompt.testing` -> `false` You’d then need to enable a CDM as well. For Widevine on desktop, you’d want to set: - `media.gmp-manager.updateEnabled` -> `true` - `media.gmp-widevinecdm.enabled` -> `true` I considered adding a Phoenix-specific preference to streamline/make this easier to control, but I decided against it *(because A: I’d like to keep Phoenix-specific preferences to a minimum and B: it’s not something we officially support or recommend)*. So, in theory, LibreWolf could just override these preferences and/or add ex. UI toggles to control them.

degausser commented 2026年05月23日 21:04:55 +02:00

@MahoganyPrime @celenity

usable drm support in librewolf (and most other community forks too) isn't just a matter of having the right prefs set and mozilla drm blobs downloaded, see #2714 for example; ironically if drm playback is a priority (standard youtube playback isn't drm-protected yet btw), phoenixed official firefox build with prefs flipped accordingly is the easier way.

@MahoganyPrime @celenity usable drm support in librewolf (and most other community forks too) isn't just a matter of having the right prefs set and mozilla drm blobs downloaded, see https://codeberg.org/librewolf/issues/issues/2714 for example; ironically if drm playback is a priority (standard youtube playback _isn't drm-protected_ yet btw), phoenixed official firefox build with prefs flipped accordingly is the easier way.

any1here commented 2026年05月23日 21:49:28 +02:00

@degausser wrote in #2823 (comment):

@MahoganyPrime @celenity

usable drm support in librewolf (and most other community forks too) isn't just a matter of having the right prefs set and mozilla drm blobs downloaded, see #2714 for example; ironically if drm playback is a priority (standard youtube playback isn't drm-protected yet btw), phoenixed official firefox build with prefs flipped accordingly is the easier way.

Unless you got a spare 10k for a license lying around ;)

@degausser wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-15737930: > @MahoganyPrime @celenity > > usable drm support in librewolf (and most other community forks too) isn't just a matter of having the right prefs set and mozilla drm blobs downloaded, see #2714 for example; ironically if drm playback is a priority (standard youtube playback _isn't drm-protected_ yet btw), phoenixed official firefox build with prefs flipped accordingly is the easier way. Unless you got a spare 10k for a license lying around ;)

MahoganyPrime commented 2026年05月24日 00:13:09 +02:00

@any1here wrote in #2823 (comment):

@degausser wrote in #2823 (comment):

@MahoganyPrime @celenity
usable drm support in librewolf (and most other community forks too) isn't just a matter of having the right prefs set and mozilla drm blobs downloaded, see #2714 for example; ironically if drm playback is a priority (standard youtube playback isn't drm-protected yet btw), phoenixed official firefox build with prefs flipped accordingly is the easier way.

Unless you got a spare 10k for a license lying around ;)

Okay, I see there is a license issue that goes beyond having the right plugin installed and proper flags enabled. I think I have seen this issue during early Vivaldi days.

The use case I have is mostly for family and friends who live in YouTube to watch full featured movies. These are the free with ads movies and YouTube TV. I can't speak of spotify and the others.

Being the tech guy of the group I had onboarded them over to LibreWolf but with that some websites they use have issues. I tried solving those issues with FF+Phoenix but with that comes YouTube and maintenance issues. I recognize this is not an issue/problem with neither LibreWolf nor Phoenix as this is how each is meant to work. I just ran into this thread and saw a possible solution coming down the pipeline in the future.

@any1here wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-15738911: > @degausser wrote in #2823 (comment): > > > @MahoganyPrime @celenity > > usable drm support in librewolf (and most other community forks too) isn't just a matter of having the right prefs set and mozilla drm blobs downloaded, see #2714 for example; ironically if drm playback is a priority (standard youtube playback _isn't drm-protected_ yet btw), phoenixed official firefox build with prefs flipped accordingly is the easier way. > > Unless you got a spare 10k for a license lying around ;) Okay, I see there is a license issue that goes beyond having the right plugin installed and proper flags enabled. I think I have seen this issue during early Vivaldi days. The use case I have is mostly for family and friends who live in YouTube to watch full featured movies. These are the free with ads movies and YouTube TV. I can't speak of spotify and the others. Being the tech guy of the group I had onboarded them over to LibreWolf but with that some websites they use have issues. I tried solving those issues with FF+Phoenix but with that comes YouTube and maintenance issues. I recognize this is not an issue/problem with neither LibreWolf nor Phoenix as this is how each is meant to work. I just ran into this thread and saw a possible solution coming down the pipeline in the future.

vxl commented 2026年06月21日 19:04:41 +02:00

I think it is important to mention that Arkenfox user.js will very soon be in an EOL state.

For the record, I consider this project to be near EOL and was leaning towards v153 (the next ESR version) as being the last release - so here's hoping we get more diffs from earthlng - if not, then this is most likely it

No. If I end it,l I end it. Each ESR is still a year's worth of changes

Sources: https://github.com/arkenfox/user.js/issues/2042#issuecomment-4284156237 https://github.com/arkenfox/user.js/issues/2042#issuecomment-4584960064

Therefore, I strongly encourage the LibreWolf maintainers to rebase their librewolf.cfg, in the long term, on another project, if they do not want to maintain their own. This does not necessarily have to be Phoenix, but I believe it is worth considering.

A whole zoo of random custom third-party lists for uBO is one example.

But I must agree that there are parts that do not fit LW – in particular, this one. I already spoke to @celenity about it in the context of IronFox (a hardened Firefox fork for Android), but we ended up not agreeing on most issues.

I think it is important to mention that **Arkenfox user.js will very soon be in an EOL state.** > For the record, I consider this project to be near EOL and was leaning towards v153 (the next ESR version) as being the last release - so here's hoping we get more diffs from earthlng - if not, then this is most likely it > No. If I end it,l I end it. Each ESR is still a year's worth of changes Sources: https://github.com/arkenfox/user.js/issues/2042#issuecomment-4284156237 https://github.com/arkenfox/user.js/issues/2042#issuecomment-4584960064 Therefore, I strongly encourage the LibreWolf maintainers to rebase their librewolf.cfg, in the long term, on another project, if they do not want to maintain their own. This does not necessarily have to be Phoenix, but I believe it is worth considering. > A whole zoo of random custom third-party lists for uBO is one example. But I must agree that there are parts that do not fit LW – in particular, this one. I already spoke to @celenity about it in the context of IronFox (a hardened Firefox fork for Android), but we ended up not agreeing on most issues.

alyx161 commented 2026年06月21日 20:20:45 +02:00

We don't really follow Arkenfox since a good while now.

We don't really follow Arkenfox since a good while now.

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

@vxl wrote in #2823 (comment):

A whole zoo of random custom third-party lists for uBO is one example.

But I must agree that there are parts that do not fit LW – in particular, this one.

LW already uses their own custom uBo config, so they should be able to continue using that config if they decide to use Phoenix as a base.

In general, if LW chose to use Phoenix as a base for its config, it should be possible to override any undesired/unwanted behavior (and if it wasn't possible for some reason, I'd be more than willing to make any necessary changes from my end to make it work). I don't expect LW to agree with 100% every decision Phoenix makes, just like I wouldn't expect them to agree with every decision some other config makes either. Even IronFox (a browser I develop directly, which also uses Phoenix as a base) overrides certain prefs/behavior from Phoenix where suitable. Not trying to say this to invalidate your point or anything @vxl - I do think it's valid and important to consider what parts of Phoenix may not fit for LW (so that LW can override them accordingly if they do decide to use it) - just want to emphasize that it's not an all-or-nothing package. I think this would also apply to any other config/similar project LW might use.

---

For the record, I do want to say I strongly disagree with this characterization of Phoenix's uBo config:

A whole zoo of random custom third-party lists for uBO is one example.

(Not trying to say Phoenix's uBo config is perfect or anything, definitely worthy of criticism - I just don't think this is an accurate or fair representation of it).

But I'd rather not get into it...

(I know this isn't your words @vxl, you were quoting the serge guy - I saw his reply before but chose not to engage, for reasons I assume/hope are obvious 🫠).

@vxl wrote in https://codeberg.org/librewolf/issues/issues/2823#issuecomment-17840336: > > A whole zoo of random custom third-party lists for uBO is one example. > > But I must agree that there are parts that do not fit LW – in particular, this one. LW already uses their own custom uBo config, so they should be able to continue using that config if they decide to use Phoenix as a base. In general, if LW chose to use Phoenix as a base for its config, it should be possible to override any undesired/unwanted behavior *(and if it wasn't possible for some reason, I'd be more than willing to make any necessary changes from my end to make it work)*. I don't expect LW to agree with 100% every decision Phoenix makes, just like I wouldn't expect them to agree with every decision some other config makes either. Even IronFox *(a browser I develop directly, which also uses Phoenix as a base)* overrides certain prefs/behavior from Phoenix where suitable. Not trying to say this to invalidate your point or anything @vxl - I do think it's valid and important to consider what parts of Phoenix may not fit for LW *(so that LW can override them accordingly if they do decide to use it)* - just want to emphasize that it's not an all-or-nothing package. I think this would also apply to any other config/similar project LW might use. ___ For the record, I do want to say I *strongly* disagree with this characterization of Phoenix's uBo config: > A whole zoo of random custom third-party lists for uBO is one example. *(Not trying to say Phoenix's uBo config is perfect or anything, definitely worthy of criticism - I just don't think this is an accurate or fair representation of it)*. But I'd rather not get into it... *(I know this isn't your words @vxl, you were quoting the serge guy - I saw his reply before but chose not to engage, for reasons I assume/hope are obvious 🫠)*.

vxl commented 2026年06月29日 23:04:10 +02:00

just want to emphasize that it's not an all-or-nothing package. I think this would also apply to any other config/similar project LW might use.

Yes, that is basically what I meant in my original statement. I specifically said that (emphasis added):

Therefore, I strongly encourage the LibreWolf maintainers to rebase their librewolf.cfg, in the long term, on another project, if they do not want to maintain their own. This does not necessarily have to be Phoenix, but I believe it is worth considering.

you were quoting the serge guy - I saw his reply before but chose not to engage, for reasons I assume/hope are obvious 🫠

Yes. While I personally disagree with the approach Phoenix took in its uBO config, I do not agree with @sarge's statement. The quote was meant to refer to the already discussed uBO config, since I also believe it shouldn't be adopted by LW.

> just want to emphasize that it's not an all-or-nothing package. I think this would also apply to any other config/similar project LW might use. Yes, that is basically what I meant in my original statement. I specifically said that (emphasis added): > Therefore, I strongly encourage the LibreWolf maintainers **to rebase their librewolf.cfg**, in the long term, on another project, if they do not want to maintain their own. **This does not necessarily have to be Phoenix, but I believe it is worth considering.** > you were quoting the serge guy - I saw his reply before but chose not to engage, for reasons I assume/hope are obvious 🫠 Yes. While I personally disagree with the approach Phoenix took in its uBO config, I do not agree with @sarge's statement. The quote was meant to refer to the already discussed uBO config, since I also believe it shouldn't be adopted by LW.