It is absolutely not reasonable.
It completely goes against the entire goal of what FPP and RFP seek to achieve.
They’re selectively altering the profile of each depending on website based solely on @celenity’s arbitrary judgement.
If their goal is to minimize breakage they should solely use FPP.
If their goal is maximum resistance they should solely use RFP.
Doing something in between like they are is a very wrong approach to the compatibility issue.
As others like @sha123 have said for months: no it does not.
It doesn’t do anything.
The Fission implementation on Android simply runs some tasks in a separate process, there is zero security boundary between processes.
And said processes can still read/write all data the app has access to.
This question has been repeatedly asked in this thread.
I don’t understand why people refuse to read.
Any page that can successfully gain RCE can trivally phone home with your cookies and passwords without worrying about a sandbox.
Firefox 142 even fixed an issue like this in their GMP process, although it didn’t apply to Android, it shows that such issues can and do exist.
This kind of talk does not belong on this forum kindly.
This may be true, but if this would be such an important Criteria that if a Browser doesn’t fulfills that Criteria it wouldn’t be recommended, FireFox wouldn’t be recommended by Privacy Guides. But since that isn’t the case, this can’t be used as an argument for don’t recommending IronFox.
We have to wait and then to see if the security updates are regular and timely applied to IronFox.
I did a table on that. And if you look at that table, you can clearly see: Yes, they are. They are even much faster applied to IronFox than to Cromite, which is recommended.
Brave is IronFox, but better since it uses Blink which is more secure and the security fix delay is shorter than the security fix delay of IronFox.
With this argument you could remove many existing Privacy Guides Recommendations, so unless this many Recommendations aren’t removed (which I think won’t happen ), it’s not valid.
IronFox doesn’t add something to Firefox what can’t already be archieved.
Finally, I wan’t to add a thought that is completely independent of the above arguments and separate, this isn’t an argument for adding IronFox (unless it is valid). And this is maybe or even probably big trash, this may be the biggest shit you’ve ever read. But I thought, that Gecko could be not that more insecure than Blink because it has a market share of only 2 %, so if a cracker wanted to use security vulnerabilities, he would probably look to the source code of Blink to find security vulnerabilities instead of looking to Gecko since Blink has a market share of 80 %. So unless Gecko would be 40 times more insecure and easy to crack, I think a cracker would go to Blink so he has more profit with having less work and when I look to the different security fixes of Chrome and FireFox, it seems to me like the security fixes are so completely different that I think, security vulnerabilites found in Blink which a cracker would use aren’t in Gecko (or at least with a very low probability) because these two rendering engines are completely different.
@celenity maybe a silly question but what does enabling memory tagging support for IronFox actually entail? Is it modifying Firefox’s memory allocator to make it MTE-aware or maybe opting in to MTE/Advanced Protection when it is available? Is there any change if you were using IronFox on GrapheneOS and had not disabled “Memory Tagging”?
I deleted Iron Fox after noticing with Rethink DNS that it sends data in the background. Even when closing the browser with the “clear all on closing” feature enabled, the history still remains in the recently closed tab, which is very bad for forensics.
Never used Mull as have only just started using the various privacy tools and being aware of them. I use Tor as a browser. Would Iron Fox offer anything different/better?
All of those connections are perfectly reasonable for my threat model… except for geolocation. Am I reading it right that unless you go out of your way to remove the beacondb URL from the geo.provider.network.url setting in about:config, and if location is disabled system wide, ironfox will basically override and provide geolocation data anyway? If so that should really be OPT IN not OPT OUT. Hopefully I’m just misunderstanding….
Edit: okay I think I jumped to an erroneous conclusion. That must be for if geolocation IS enabled systemwide and the default, for whatever reason, is unavailable. I have geolocation DISABLED system wide, and without changing anything in about:config, browser checks for geolocation are returning “denied by user” and such messages.
), it’s not valid.