A New Phoenix

Hi folks, Phoenix is currently undergoing some large, fundamental changes - which I think you will like. **Going forward, Phoenix will be entirely local.** - No more remote AutoConfig server. Updates will still be distributed automatically, however will now be done via your package manager. Going forward, all you will need to do is simply install the 'phoenix' package for your operating system of choice *(of course in addition to Firefox itself...)*. **Fully manual installations of Phoenix will still be supported, though will serve little purpose with this new approach** To outline why I've decided to go in this direction, I'll list the following benefits to the new approach: * Faster: Firefox appears to launch **significantly** faster in my testing when the config is local. This makes sense, as the browser no longer has to constantly download and process the .cfg file - though I'm genuinely surprised at just how much of a different it makes - it's jarring. I'm interested to hear what users will think/if others will also notice this. * Smoother & simply works better: I've observed bugs with the current remote AutoConfig approach - such as the browser not launching without internet access in some cases. Issues like this haven't been widespread, but have still been issues nonetheless. * More private & secure - At https://codeberg.org/celenity/Phoenix/issues/18, the privacy & security of using a remote AutoConfig like this was discussed by myself & others. I outlined the approach we take to protect users and mitigate potential risks [here](https://codeberg.org/celenity/Phoenix/issues/18#issuecomment-2490737) - and while I feel these steps were generally effective and that this was a safe approach, it still posed some concerns (as highlighted in the previous link). It also required us to make compromises to protect users, such as locking Firefox's default homepage (so that we or anyone couldn't override it to a malicious website), requiring users to manually edit their local files if they wanted to change it. **This is the exact type of thing Phoenix is against - and was a major reason I started this project in the first place!** I don't want users having to dig around and editing config files or setting overrides like this. That was (and still is) a **major** problem of other approaches for configuring Firefox (ex. `user.js` files). I don't think you should have to be an advanced user to be able to take advantage of Phoenix at its core, and I still don't. There were also simply security issues with the remote AutoConfig approach itself - for instance, AFAIK it doesn't verify file integrity (ex. via checksums). This approach gives us a more private & secure way to configure Firefox, and as privacy & security is one of this project's biggest goals (if not THE biggest goal), it just makes sense. * Control: This approach also gives more freedom and control back to users, which is one of this project's other main goals (besides privacy & security)! Instead of us being able to rapidly & automatically update preferences, users will now be able to easily review our changes & decide for themselves whether they want to update or not. If we release an update a user doesn't like for whatever reason, they can simply not install it. *(Though we still strongly recommend & encourage enabling automatic updates via your package manager!)* * Simplicity: **All users have to do now is install one package, and it will handle the rest for them automatically:** that's it. This makes the project far more accessible and easy to use. **By the same token, if users decide Phoenix is no longer for them and wish to uninstall it, this is also far easier - simply remove the package, and you're done.** * No compromises: **This new approach doesn't compromise the effectiveness of Phoenix in any way, shape, or form** - it is still far more comprehensive than any simple user.js file, and doesn't compromise security like forks do - we're still using Firefox as a base in the same way, meaning you still get immediate updates from Mozilla/your package maintainer. * Just made sense: We're already packaging policies anyways... why not package the rest too? There are downsides to this approach, the most notable being: * If a certain pref or feature is being abused or exploited in the wild, we can no longer rapidly toggle it. This is why enabling automatic updates is still important & highly recommended. Mozilla already has similar infrastructure in place for this though (Via their 'Blocklist' feature & 'Remote Settings'), so realistically this is something they would handle. We would also still be able to push out updates to counter it in theory. Overall, I feel like this is the best direction for the project going forward, and I'm interested to hear thoughts & feedback on this.