The question is if the flaws are mitigatable, or by design. Feasibility is not just technical but also economic/social: the issues are known for long but not mitigated, and a clear roadmap that is just to be implemented seems to not exist either. So that leads to questions that should be tackled before spreading this technology imho. Just spreading a technology, and manifesting/stabilizing its current condition (including the condition of the organization(s) that develop/maintian it), can cause problems to remain, as the organization emphasizes on other things if they are not forced to tackle these issues immediately. This makes it harder to get rid of it later, may it be social/economic or technical origins of the problems.
I am curious, do you know how is the āstrong reasonā determined?
I like that, but I see many single points of failure (and denials of service when flathub gets widespread some day) if people are involved in doing that, including in determining āstrong reasonsā.
Well, with sysadm_u, we could soon fit all people who are satisfied by Fedora as it is shipped, plus major applications - thatās above 1% Iām sure. But you are right that we have to also consider users who use minor / less widespread applications, and here things get less reliable with confined users.
I cannot say much here, thatās indeed correct. This does at least doesnāt question its current use, but you are right that this questions (in any case, causes challenges about) a deeper embedding into user accounts. I admit my argument of above here applies to SELinux as well, when it comes to imposing it within user accounts to help isolating applications within.
In its unconfined_u state, I see only advantages. And a MAC should be enabled on any system. SELinux does a well job and adds much security, especially preventative security, without imposing issues to users. It is indeed something to be debated if we shall increase confinement conditions and imposing it within user accounts, but disabling unconfined_u should be no option, neither on server nor client. We need a MAC, and the trend clearly goes that any major Linux distro adopted one. However, that said, I feel not qualified to determine if AppArmor (SuSE, Ubuntu, Debian, ā¦) is better suited for maintaining MAC in flatpak environments, as I do not know much about it. But as it focuses on profiling files, well, I admit that might be possible.
Matter of debate 
That doesnāt work. SELinux policies rely on review and testing, just like code. Its hard and complex work.
We have WGs and SIGs that take care that the major Fedora variants contain stuff that is maintained by trusted maintainers, many people watch it - maybe not any malware injection would be immediately found, but the people could be likely identified, and maintainer-independent infra and testing causes risks for the attacker to get revealed: Especially with major packages, persons who maintain are known, mostly personally. Keep in mind that this has a social element: such an attack has consequences, and a person with the qualification to conduct it is likely to be sufficiently intelligent to be aware of that: We have an infra any package has to pass (auto tests, peopleās testing) with maintainer-independent elements, and this leads to risks to get revealed as the maintainer cannot corrupt the infra, but it also limits the attack vectors (higher risk, lower outcome). This at least increases the entry barrier to this behavior. But you are right that the risk is much higher for packages that only a minor number of users are using: the risk exists especially for less known packages from maintainers that are also less known.
However, I think the issue in flatpak is much worse, as not even the infra for building and testing is imposed on the maintainers, is it? (Again, I might be wrong about the current state of flatpak?)
I have to disagree here: In ask.fp, we regularly have cases of users who experience problems and we find out the origin is third party repos, that are badly maintained, packages aināt really tested and worse. Many just try to create some rpms that work and then ship it to their repos. That said, I agree to your argument of rpmfusion , which I actually do not consider a third party repo (although it officially is).
I agree that there are really issues with RPM, and I had many conversations with maintainers and other people that we need to change much, but so far, I see no advantages of flatpak: There might be more standardization and more people to maintain, but it does not impose what is necessary to make this useful for security: homogeneous testing, homogeneous infra, and both independent of the maintainers themselves, who might remain unknown, without a SIG or WG that at least takes care who the maintainers of the major packages (such as browser) are. Or has flatpak introduced something concerning these issues?