Arkenfox is militantly maintained to only change what really matters. The rest is just adding unnecessary complexity.
Android doesn’t support this afair.
This is way too many changes that’ll ultimately slow down each major update.
This is not stable and very broken.
I was also disappointed to see that IronFox did the 134 update without contributing upstream to Fennec F-Droid like I did for years.
Disagreed. We still follow Arkenfox closely & add their changes where relevant. Also worth noting that we’re not the only ones who feel these are important additions, as other privacy & security browsers have also applied several of them similarly.
You yourself made your own changes on top of Arkenfox as well…
We tested it and found it indeed works. We also explicitly exclude local IP addresses regardless (even in trusted scenarios) to be safe.
Valid concern - but thankfully, the relevant patches are not complex, and we plan to further simplify them with time. We’ve already substantially simplified and improved the build process itself, and will continue to do so.
I would like to see evidence to support that this is still the case, because this doesn’t seem to be the current consensus at all based on my research.
Your trial enabling it with Mull was several years ago; fission has progressed since then, to the point Mozilla is even beginning to officially roll it out on Nightly. We’ve also exposed a UI option to disable it in the case it does cause issues. If folks do have problems like you suggest, we’ll revert it.
I personally contributed to Fennec to help clean-up the pre-build script, and I (as well as the other maintainers) will continue to contribute to Fennec & help where possible.
Your feedback is appreciated.
It’s not 15 or 10.
Good luck. This is just arkenfox, designed for desktop, Mull used brace which is a fork of it + a bunch of other stuff, and managed in different places because mobile/setting these configs as defaults may not always apply properly. You truly can’t just trust yourself to do this kind of thing. It doesn’t work and you’ll miss stuff out.
IronFox is doing a good job IMO with those.
It will.
Understandable. Directly in the config itself (Ex. Phoenix/android/phoenix.js at pages - celenity/Phoenix - Codeberg.org) itself, we do add notes above the prefs we configure, with sources and additional information as to why we set it (similar to how Arkenfox & other similar projects do). You make a good point though with how Arkenfox utilizes issues for certain changes to discuss them, so I think we’ll try to incorporate more of that with Phoenix & IronFox going forward. That being said, you or anyone else is always more than welcome to discuss any specific changes we make.
Don’t worry, we will continue to be transparent regarding our changes and rationale for making them, and will always be open to feedback.
Is anybody else getting super bad performance after installing todays update?
I can’t even load the extentions page to configure uBlock, everything is so slow and clunky all of a sudden?
Sorry to hear that. We haven’t heard any other complaints regarding performance so far.
To confirm, you’re on v134.0.1? Have you made any additional changes before you started getting this bad performance?
My first suggestion would be to try disabling Fission and see if that makes a difference. You can see the steps to do this on our GitLab release here. I’m not sure if it will help or not, but that’s probably the biggest change we made this release, so it immediately comes to mind.
I’ll keep you updated if we hear of similar issues from others and can find a cause.
Thanks for your response, I will check the guide and see if I’m able to follow it.
Below is a photo of what the uBlock dashboard looks like for me and I am indeed using 134.0.1 & have made no changes or modifications.
I will update on whether your suggestion improves the situation or not.
Update: I followed the guide without issue and disabled the new setting but sadly that only made a slight improvement, it’s still nothing like the version before this.
I also noticed some changes you make are hard coded and can’t be edited, is a piece of software truly FOSS if elements are locked by other people?
I was looking to re-enable site suggestions when I discovered you can’t, now people need to type youtube.com rather than just typing y and tapping youtube. 
I’ve had to choose between downgrading the version of IronFox or using Brave instead, does this latest release patch any vulnerabilities?
Sorry to hear that, it doesn’t sound like Fission was the culprit so I’d recommend re-enabling it.
To confirm, have you made any additional changes to IronFox, do you have any extensions installed, etc? We still haven’t heard anything from anyone else regarding performance issues, so it’s quite strange you’re running into this. Do you mind sharing a screenshot of about:processes?
We’re trying to only lock prefs related to telemetry/data collection & ones that are critical to privacy & security. I’m interested to hear what you were trying to change but couldn’t? I think we do probably need to find a more consistent policy of when vs. when not to lock something.
I’m not exactly sure what you’re referring to here. If you’re referring to search suggestions, you can indeed re-enable them by navigating to IronFox’s Settings → Search. You can also re-enable Autocomplete via the Autocomplete URLs option at the bottom of the same menu. We also leave ex. suggestions for bookmarks on by default, so having YouTube bookmarked would cause it to pop-up in your case. I’d appreciate more details on this.
This release was mainly performance related, though it did fix memory leaks on certain Google/YouTube sites - which could pose security risks.
Also @bigsmoke are you able to file an issue on our GitLab? That’d help us stay organized & better track this, and would also prevent us from hijacking this thread more than we already have…
I have made no changes or modifications to the app and the only add on I installed is just uBlock.
When it comes to being unable to re-enable search suggestions I mean in relation to:
“If Autocomplete is enabled, Mozilla’s shipped domains list has been disabled. This is a list of popular sites created by Mozilla for use with autocomplete - though was created several years ago and subsequently abandoned, posing security risks due to domains changing hands.”
This makes well known and highly used sites like youtube and wikipedia no longer show up which means each user has to type each address. This gives room for people to make typo’s and end up on malicious clones of well known sites, this is a known attack method already used in the wild.
I don’t own a Gitlab account but will create one if you are unable to create a note of this.
Included below is a copy of about:processes.
To better explain why we disabled the shipped domains, I’ll quote a Mozilla employee:
Android’s current list of 400+ domain names for address bar suggestions was created way back in December 2015… This list hasn’t been updated since 2015 and now includes expired and squatted domains that might serve ads or malware. Instead of updating the lists of top domains, we should remove it. This would avoid the risk from future bad domains. The default suggestions are out of date and not necessarily relevant for every locale.
I think that speaks for itself… Based on the issue from Bugzilla, it looks like this is being removed from Firefox in the future as well, and its removal is already being rolled out on Nightly. We could consider implementing our own list of ‘shipped domains’ instead, though we’d need to keep it at a minimum to ensure we can maintain it to avoid repeating Mozilla’s situation…
In the meantime, you can simply bookmark YouTube (or whatever other website you’d like), and IronFox should recommend it to you in the URL Bar/Suggestions.
FYI, on an unrelated note: We’re looking more into the prefs we currently lock and a majority will be unlocked next release. We already try to keep it at a minimum, though we do think we’re probably locking too much as it stands. Like I said above, our goal is to only lock prefs that are either related to telemetry/data collection/etc. or ones that are especially dangerous.
You don’t have to by any means, but it would be appreciated. What you’re experiencing sounds like a serious issue and we need to get it fixed.
That was quick!
Here’s a link for others who are interested: Comparison - celenity/Dove - Codeberg.org
Today it is actually somehow running better, the only complaint performance wise is a big lag when typing, I type a word and it comes up a few seconds later and at a rate of about 1 letter per second.
I also noticed IronFox doesn’t hide public WebRTC IP or spoof system time?
I’m confused, where is IronFox on that list of charts?
Nice to hear it’s at least better. FYI: Someone in our Matrix channel had performance issues (though not as severe as you’ve had), and said they went away after reinstalling IronFox. That’s of course not ideal, but it may be worth trying if you’re able to.
Why would we hide the public WebRTC IP? As the name suggests, it’s public. Due to how the internet works on a fundamental level, you will always expose your public IP to the websites you go to, and you can’t really get around that. It’s not a leak. If you use a VPN, the public WebRTC IP will also match your VPN’s IP. This is information already being exposed and it’s unclear where the privacy risks is here. FWIW: We do forcefully exclude local IP addresses from WebRTC, which are where the real leak and privacy concern lies.
or spoof system time?
AFAIK we still do. Did you disable privacy.resistFingerprinting? If not, I’m curious to hear why you believe this to be the case.
It’s not, and it isn’t supposed to be. They were referring to me adding Betterbird to Dove’s comparison table.
I just noticed it because Mull did block public WebRTC so I expected IronFox would do it too.
I also didn’t disable resist fingerprint (which I assume you would have locked for previously mentioned reasons but I guess not) but checking IPleak.com - IP leak test gives me an alert that my system timezone and IP timezone don’t match, the system timezone shown is my real timezone.
I thought the point of the comparison table was to show how IronFox differs to Mull?
Mull fully disabled WebRTC because iirc it used to not be properly protected against leakage; though this is no longer the case with the prefs we set, and leaving it unnecessarily disabled can aid fingerprinting.
RFP sets the timezone to UTC-0, so unless you live in an area that is currently under UTC-0 (or unless you’re using a VPN located in an area that uses UTC-0), it will always claim the system time is different from the IP time. This should be the same for Mull.
There are 2 separate tables. The table @Cue and I just referred to is for a separate, unrelated project (Dove, which is for Thunderbird hardening on desktop). I am indeed working on a table that compares Firefox derivatives on Android, but that’s not what we were referring to.
My mistakes, sorry.
