I think that @sha123 is trying to point out that even though fission has been enabled, it is currently not comparable to chromiums site isolation and that there is a reason its still disabled by firefox by default on android.
this is an example of valid complaint to have which is why I prefaced this in the last line.
You have proven exactly nothing, only that he enabled a very early version of Fission.
This is not proper site isolation in its current state!
And if you just read the whole discussion around it you would have realized that:
No, not only not comparable, there is no proper site isolation in its current state. Pls change the title of the above thread because people just stop at reading the title without the discussion and draw wrong conclusions.
1 Like
Gave it an edit.
1 Like
That’s better. Thx
Yes, isolated process enforced by SELinux is still not used in any of these afaik.
2 Likes
hi @celenity , love the project! 
Do you know if the Matrix room is still up? I just found out about the project and wanted to join the room to keep myself up to date with the development.
Thank you in advance.
1 Like
I have nothing against your project. I am against recommending any FF-based browser on Android, including Ironfox. It is not your fault that Mozilla has treated Android security like it did. You do what you can to make the best out of it. Nevertheless security shortcomings are significant (again, not your fault), should be clearly mentioned and discussed before a recommendation can even be considered. You might also want to change your documentation because it makes it seem like site isolation is actually properly enforced, which it is not.
5 Likes
hmm, @celenity I think something is off with the room because it says I’ve no permission to write there. Also can’t see anyone writing.
thanks @celenity , this one works fine 
1 Like
IronFox (and Phoenix) must not be recommended at all.
They’re wrongly applying an egregious amount of per-site overrides, fundamentally breaking the given crowd aspect of either FPP or RFP on their own.
This results in users of IronFox having uniquely evident fingerprints.
Additionally the criteria for these exceptions is completely arbirtary and undefined.
It also breaks the given understanding of how fp resistance should work.
They’re basically pulling a KickSecure: taking something insecure (Debian) and putting 1 trillion million changes on top to make it “secure” to fool users.
Avoid!
2 Likes
For the curious (i was), here’s the devs reasoning for what AstraKitten pointed out:
IMO, this seems like a reasonable approach for the threat model they’re aiming to protect against, i.e. naive finger printers, per their own Limitations and FAQ pages.
While this does result in not maintaining the same finger print as firefox users with RFP enabled, the overrides seem relatively minor and make it so you’re NOT stuck needing to choose between RFP+breakage or no protection at all.
This was a good reminder for me to actually review a projects github/lab/codeberg tho, I wasn’t aware of this.
edit: messed up the link, lol
2 Likes
Does IronFox have site isolation at all? Does Firefox on Android still not support it?
Or a Secureblue. You could also say the same for Proton and Tuta since email can’t be made secure or private (E2EE is useless at best).
1 Like
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.
Seems like IronFox has enabled site isolation.
If security is the top priority here even Opera is leagues ahead of Firefox, and Opera is a Chinese privacy nightmare.
4 Likes
I’ll wait until we have solid proof that this is secure and private.
Their website provided on gitlab isn’t even on https. With how simple it is to set up https, I wouldn’t ignore that for now.
1 Like
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.
1 Like
I wish I didn’t have to say that but any maintained Chromium fork is most likely way more secure than Firefox.
- Non-Blink Browsers are insecure.
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.
(By the way, I couldn’t upload the original .odt–File, I’m wondering why .odt-Files aren’t allowed for upload?
)
- 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.
That’s not true, see that reply: IronFox (a new Mull fork) - #15 by celenity
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.
7 Likes
zzzz this is too much of a generalisation and sends the wrong message. especially when people are trying to avoid using Chromium based browsers…
2 Likes