Add Phoenix support #230
Loading…
Reference in a new issue
No description provided.
Delete branch "pho"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What?
Instead of having own config profiles we now become Phoenix browser? O.o
@alyx wrote in #230 (comment):
It adds the option to enable Phoenix, which is off by default.
I know
I just don't understand why we do this instead of what was discussed since over a year
@alyx wrote in #230 (comment):
Phoenix isn't replacing LW's default config here, it's just a separate option for users to enable if desired (to ex. improve their privacy and security). When it is enabled, it simply complements LW's default config and gets combined with it.
@alyx wrote in #230 (comment):
I'm not sure what specifically you mean by
instead of what was discussed since over a year, but, in general, I think the thought process/rationale is to provide an official/native way for LW users to use Phoenix (and thus take advantage of the privacy and security improvements it provides). It's currently not easy or user-friendly to install Phoenix on LW, so this would significantly lower the bar to entry and allow more LW users to take advantage of Phoenix's enhanced privacy and security (and other features).As a full owner member of this org, you are free at any point to contribute to the LW settings you find lacking.
@celenity wrote in #230 (comment):
The discussion was about the fact that LibreWolf has a highly split userbase.
One part of them would like to use LibreWolf as a Firefox without the bloat, while others are looking for a privacy focused browser, like for example Tor/Mullvad.
Everything we do in terms of settings is usually a bad compromise that makes no side really happy.
Therefore the idea was, eventually to offer 2 profiles / config presets what ever you wanna call it, one security focused that is was suppose to go more in the Phoenix direction, and one that is a lot less aggressive and has a lot better UX.
While that may be true, and I don't wanna sound mean here, but that doesn't really justifies LW to glue on a Phoenix mode, in my opinion.
I have the feeling this is more something that should be part of the installation tooling Phoenix itself provides.
I also see an issue with the fact that, in its current form, this gives the implication that the user is using Phoenix, while its just using a subset of it.
Could someone explain what exactly is the benefit of using Phoenix with LibreWolf over using Phoenix with Firefox?
First off, I really like Phoenix, the way it's set up, documented and maintained, so that's not what this is about.
This is also unclear to me: with this PR, the option would be offered without properly informing the end user about what it actually offers compared to LW's default prefs set. Just saying it provides "privacy and security improvements" is not enough. Nobody can properly make a decision based on just that and it maybe even implicates that LW does a bad job at this out of the box. Phoenix will also introduce new obstacles compared to the LW prefs set, so users show be informed about that.
It also introduces the issue of having to support two perfs sets. Issues will be created for both situations, probably quite often without specifying which set has been used.
@alyx wrote in #230 (comment):
Likewise? I don't really know what your point is here?
@alyx wrote in #230 (comment):
I don't really agree with the claim about Phoenix being super aggressive, it goes to a major extent to provide a balance between privacy, security, and usability/comfort.
But anyways, I'm also pretty confused, because your idea of offering a separate Phoenix-like config/preset for users to select doesn't sound that different from this PR?
I very strongly disagree. No installation method Phoenix could provide would come remotely close to the ease/convenience of simply clicking a button to apply the config. It removes the need for all manual/additional set-up, the need for users to maintain the installs/keep them up to date, etc. Having native support significantly lowers the burden of entry and makes it far more accessible to more users (which should be considered a net win, as it means many more users can take advantage of the enhanced privacy and security, as well as other features it offers).
Well, AFAICT the only aspects technically missing in this PR are Phoenix's policies and environment variables. I don't consider the environment variables to be an issue (Because AFAIK LW pretty much already covers them). The policies are the bigger issue, but there is a lot of overlap between Phoenix's policies and the policies LW already sets, so I don't think it's a major concern either (Biggest aspect missing is Phoenix's extension blocklist, which is unfortunate and I do hope there's a way for LW to support it with Phoenix installed as well), though it isn't ideal.
The main benefit is the fact that LW provides certain features that are not possible to accomplish on stock Firefox w/ Phoenix (ex. EME permission, WebGL permission, compiler flags, disabling ex. telemetry at build-time, the Remote Settings blocker, etc.).
So providing a mechanism for LW users to use Phoenix would effectively allow them to take advantage of the best of both worlds.
@ltguillaume wrote in #230 (comment):
IMO this could be resolved by adding a FAQ entry/documentation and linking to Phoenix's wiki page. I agree with you that some information/background should be provided to the end-user.
That's an understandable concern, but I feel like this could be mitigated by ex. adding an entry to the issue template for users to confirm if they're using Phoenix. I think adding a disclaimer that issues with Phoenix should be reported to Phoenix's issue tracker instead of LW's would also help, so that people are directed to the right place.
Really excited for this to land in librewolf.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.