I’ll share my perspective on why I prefer the Session/Matrix approach over the F-Droid approach in this instance, for your consideration.
These two cases are the only instances where we make these “half-recommendations” for security-related reasons, if I recall correctly:
-
F-Droid’s has a major flaw (IMO), namely that packages are signed by F-Droid rather than the developer. This has significant real-world impact on regular users: it actively prevents the developer from delivering updates directly if need be, and it stops you from easily switching away from F-Droid’s repos. These usability+security concerns warrants F-Droid’s default repos being actively discouraged.
-
Element and Session have a minor flaw (IMO), which is that they don’t support Forward Secrecy. Admittedly, the threats that this actually protects against are relatively rare and advanced, because the attack requires two things: an adversary collecting past conversations, and the later compromise of long-term keys. These events being the only compromising factors are basically unheard of in the real world, but because FS is basically trivial to implement and the threat is still practical, there’s basically no excuse for a messenger not to use it.
However, we still explicitly recommend Element and Session because they have a lot of unique functionality that the alternatives lack. I feel like Mull falls closer to this category.
With that out of the way, what’s not immediately clear to me is the real-world threat that the lack of per-site process isolation actually has to most people. In fact I would argue that this security flaw is a smaller real-world problem than both of the security flaws detailed above. Thus, a full anti-recommendation feels disproportionally biased against Gecko-based browsers here.
This is why I would prefer to make an affirmative recommendation alongside a warning that provides the context of this discussion, instead of a full anti-recommendation.