You misunderstood what they said. Indeed, Android can have multiple app repositories and this is an integral part of its security model design.

However, for the security model to be respected, each app repository should represent a single source. The device and user management APIs expect that in Android. F-Droid fundamentally bypasses the trust boundaries in that regard by allowing multiple repositories to coexist within a single client.

Not to mention it also results in a terrible UX given that the application IDs are often reused but signed by another party.

> However, for the security model to be respected, each app repository should represent a single source. The device and user management APIs expect that in Android.

This is exactly the point that I was questioning, so it sounds like I understood their point just fine. Do you have a citation for this assertion?

The paper from Google doesn't even mention a repository as a concept.

Here's what it does say:

> Untrusted code is executed on the device. One fundamental difference to other mobile operating systems is that Android intentionally allows (with explicit consent by end users) installation of application (A) code from arbitrary sources, and does not enforce vetting of apps by a central instance.

The Android security model is based on the idea that you can install arbitrary APKs from literally anywhere. If I download an APK through Chrome and install it, I might turn around and download another APK from a different website. If anything, Chrome is more arbitrary in its sourcing of APKs. How does F-Droid break the security model but Chrome doesn't? Alternatively, how does Google allow Chrome to break its own security model?

And again, what is your source for your claim? I'm reading the actual document from Google, and it appears to say exactly the opposite of what you're saying.

This paper is not exhaustive and there is further documentation on the APIs in question on the Android official website. 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.

Chromium is a particular case, but is still equally considered an untrusted source unless explicitly allowed. 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.

> 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.

Sounds like a you problem: https://developer.android.com/reference/com/google/android/t... https://developer.android.com/reference/android/os/UserManag...

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.