> You can easily guess the problem involved with the security model when the OS expects an app repository to represent a source of trust, but the app in question decides otherwise.
No, I can't, because as far as I can tell there is no OS-level concept of an app repository. Where are you getting this from? Can you link to the APIs that have this concept documented?
> Of course, the security model takes into account that apps can be installed from anywhere. That's why they're signed and they're running in their own restricted sandbox.
Right. They planned that in. They spelled it out explicitly. Untrusted code from arbitrary sources is allowed if the user opts in. It's not a violation of the security model, it's a particular case that was specifically planned for.
Any regular app can be considered an installer. Such APIs like the one controlled by requireUserAction which allows seamless app updates since Android 12 are declared in the app in question, and can even allow apps to update seamlessly.
The management features, again, expect the app to represent a single source. F-Droid deliberately chooses to manage multiple sources that can also be added by the user within the same app, thus bypassing these features. That's the way they work and again, this paper is not exhaustive and is not in contradiction to anything that has been said (quite the opposite).
You still haven't explained where it is specified that the OS cares about number of "sources". I have cited the original document explaining the Android security model. I have given you the specific paragraphs that show why I think the way that I do.
In return, you suggest that the documentation is out there, but you give no specific pages that I can read. My attempts to find them on my own or through your blog post have been fruitless. Given that the idea that you're putting forward runs directly contrary to the paper that Google published and is contradicted by the behavior of Google's web browser, the burden of proof is now on you. I need your source. Please provide a link to where you arrived at your idea.
You're welcome to search for mentions of sources and app stores, and to browse the references.
Again, the paper is not in contradiction, you misread it. Not to mention, as explained in the original comment you were responding to, F-Droid weakens the security model for various other reasons.
The links you provide say nothing except something I already knew: there is a setting that tells Android to allow installing apps from unknown sources. Which proves... nothing at all.
It's obvious you're convinced you're right, but since you're unable to produce evidence it seems we are at an impasse. I'm done here.
Once again, these management features don't expect an app to bypass the trust boundaries by allowing the user to arbitrarily add repositories. There is a to-be-exposed toggle that allows user profiles to install apps from trusted sources. It wouldn't work with the way F-Droid works. I can't explain more than that.
You have been provided with evidences, but you've been arguing in bad faith since your first comment by misinterpreting the paper. The security model also expects you to download apps from trusted sources because the signature verification is only enforced for app updates, that's a trust-on-first-use model. That notion exists within Android, and you have been given examples.
> In order to ensure that it is the app developer and not another party that is consenting, applications
are signed by the developer.
Back to the original question; it is clearly explained why.
No, I can't, because as far as I can tell there is no OS-level concept of an app repository. Where are you getting this from? Can you link to the APIs that have this concept documented?
> Of course, the security model takes into account that apps can be installed from anywhere. That's why they're signed and they're running in their own restricted sandbox.
Right. They planned that in. They spelled it out explicitly. Untrusted code from arbitrary sources is allowed if the user opts in. It's not a violation of the security model, it's a particular case that was specifically planned for.