Installed from Play Store' is not a safety badge

Every application on an Android device runs under trust that was granted at the moment of installation, and the store that delivered it is where that trust was set. F-Droid 2.0 is positioned as a privacy and security alternative to Google Play. That is a claim about the trust boundary, not about a feature list.

Whatever store delivers an application defines the conditions under which that application reaches the device. It controls the channel the code travels through, the identity attached to it, and what the user is asked to accept before install. Trust placed in the store is inherited by every package the store serves. This is the structure of app distribution on the platform. It is not a setting the user opts into.

Treating F-Droid 2.0 as an alternative to Google Play only means something if the trust boundary it defines is different and enforced. A store that is easier to use but sets the same boundary is not an alternative. It is a skin. The relevant test is where the boundary sits and whether it holds. Everything else is presentation.

The standing assumption is that the default store is the security boundary. Most Android users treat Google Play as the trusted source and read ‘installed from the Play Store’ as equivalent to safe. The observable behaviour that supports this: applications arrive through one channel, the channel is understood to screen them, and the user is not required to evaluate each application on its own. Trust is delegated to the store and not re-examined after that.

That delegation collapses two separate controls into one. The store’s ability to distribute code is treated as identical to the store’s ability to account for what that code does. Distribution is a delivery function. Behavioural accountability is a review and enforcement function. The assumption only holds if the second function is as strong as the first. Nothing in the install flow demonstrates that it is.

The weak point is visibility. From a store listing the user sees a name, a publisher, and a set of requested permissions. The user does not see the review process, does not see the source, and cannot observe what the application does after it is granted those permissions. Acceptance is given against a label. If a permitted application collects and transmits data the user did not intend to share, the label still reads as trusted, because the label describes a process the user was never able to inspect. The label is a claim, not evidence. Trust delegated to a process you cannot see is trust you cannot verify.

F-Droid 2.0’s stated focus on privacy and security is, at the level of the store model, a change in where that verification can happen. F-Droid’s model is built on open-source software and published, inspectable build processes. When an application’s source is available and its build can be reproduced, the behaviour of the code is something that can be checked rather than something the user is asked to accept. The trust decision moves from ‘the store says it is safe’ to ‘the behaviour is open to inspection.’ That is a narrower and more honest boundary, because it does not ask the user to trust a process they cannot see.

The second difference is scope of dependency. F-Droid’s model does not require a Google account or Google’s service layer to distribute and install applications. Removing that dependency removes one trust relationship and one data-collection point from the install path. Fewer trust relationships in the path means fewer parties the user has to rely on and fewer places where stated intent and actual behaviour can diverge. This is a property of the F-Droid distribution model. The specific set of changes introduced in the 2.0 release, beyond the stated focus on privacy and security, is not confirmed here.

None of this makes an open store automatically safer than the default. Open source and reproducible builds change what can be verified. They do not verify anything on their own. The value depends on someone actually inspecting the source, actually confirming the build, and the store actually enforcing what it publishes. F-Droid 2.0 is a viable alternative to Google Play to the exact degree that its trust boundary is enforced and inspectable in practice, not merely stated. That distinction is the whole argument, and it is the only part worth measuring.

The failure in the default model is not that the review is weak. The failure is that the review is unobservable, and an unobservable control cannot be verified by the party relying on it. Distribution and behavioural accountability are two functions. A store can perform the first and not the second, and from the install flow the two are indistinguishable. The user accepts a permission set against a label. The label reports that a process ran. It does not expose the process, its inputs, or its result. Acceptance is granted against a claim about a control, not against the control.

Once trust is granted at install, it is inherited by every action the application takes under the permissions it was given. There is no re-examination point in the default flow. The application is not required, at runtime, to declare what it does with the access it holds. The store’s assertion at install time is the last check the user is offered, and that assertion describes a process the user could not inspect. If stated intent and actual behaviour diverge after install, the label still reads as trusted, because the label was never bound to behaviour. It was bound to the fact that a screening step occurred.

F-Droid’s model does not remove the need to trust. It moves the point where trust can be tested. Open source and published, reproducible build processes make the behaviour of the code inspectable rather than asserted. The trust decision shifts from an unobservable screening step to an artifact that can be read and rebuilt. That is the mechanism that changes: verification stops being a claim held by the store and becomes a property held in the open. Whether that property is exercised is a separate condition. Inspectable is not inspected. Reproducible is not reproduced. The mechanism creates the ability to verify. It does not perform the verification.

The pattern is general to any system that delegates trust to a process the relying party cannot observe. When the control is hidden, the user does not evaluate the control. The user evaluates a signal that stands in for the control: a label, a badge, a source name. The signal and the control are separate objects. The signal can hold while the control fails, because nothing binds them together at the point of use. Every trust decision made against an unobservable process is a decision made against its label.

This is why ‘installed from the trusted store’ carries the weight it does and why that weight is misplaced. The statement is true and still tells the user nothing about behaviour. It confirms the channel. It does not confirm what the code does once it holds the permissions granted at install. The same structure appears wherever a distribution channel is treated as a behavioural guarantee: the channel’s identity is verifiable, the channel’s accountability for downstream behaviour is not, and the second is read off the first. The mechanism is identical whether the channel is the default store or an alternative one. Changing the store does not change the structure. It only changes whether inspection is possible.

That is the specific claim F-Droid 2.0 makes against this pattern, and its exact limit. An inspectable, dependency-reduced model narrows the set of unobservable processes the user must trust. Removing the requirement for a Google account and Google’s service layer removes one trust relationship and one data-collection point from the install path, which reduces the number of parties whose stated intent and actual behaviour can diverge unseen. That is a real change to the structure. It is not a guarantee of outcome. A store that publishes source and does not enforce what it publishes has moved the label, not the boundary. The pattern holds until enforcement is demonstrated, not declared.

Define what must now be true. F-Droid 2.0 is a viable alternative to Google Play to the degree that its trust boundary is both inspectable and enforced in practice. Inspectable means the source and the build can be checked. Enforced means the store ships what it published and someone confirms it. Both conditions have to hold. The first without the second is a claim with better packaging. The specific changes introduced in the 2.0 release, beyond the stated focus on privacy and security, are not confirmed here, and no security conclusion should rest on what is not confirmed.

Controls that are not enforced are not controls. An inspectable build that no one inspects and a published source the store does not hold itself to are labels, and the failure of the default model was that its label was mistaken for its control. Moving from a closed screening step to an open, reproducible one is an improvement only if the openness is exercised. The advantage F-Droid’s model offers is the ability to verify. That advantage is realised only when the source is read, the build is reproduced, and the store enforces what it serves. Unused, it is the same delegated trust with a different logo.

The boundary is the store, and the store’s value is set by what it can prove, not by what it asserts. Judge F-Droid 2.0 on whether its build processes are reproduced and its enforcement demonstrated, not on whether it is open in principle. If a distribution model allows unstated behaviour to reach the device under granted permissions, that behaviour will eventually reach the device, regardless of which store served it. The store that lets you check is stronger than the store that asks you to trust, and only for as long as the checking actually happens.