[Replicant] [GNU-linux-libre] Criteria for Android applications

[W. Kosior]

> To fix it our current plan is to modify the f-droid client to filter
> out applications that are problematic as per the FSDG. Once this is
> been, we'll then have to upstream that feature in a way where it can
> be enabled or disabled at compilation time.
>
> This way if that works we would have 0 maintenance on the f-droid
> client side as we could then upstream a package definition for that
> version with a different build configuration (and branding) so that it
> would be automatically built by the f-droid upstream project.
>
> So practically speaking we'd share the upstream repository data and
> the f-droid client code but the modified f-droid would not show any
> problematic applications, and users could even install both f-droid
> and the version with our modification at the same time if they wish
> to, so upstream will probably not have any issue with our
> modifications as it doesn't affect the stock f-droid.

Would it be sufficient? Debian separates nonfree and free software by
putting them in different repositories but this approach is still not
sufficient to make Debian FSDG-compliant.

I understand there are some nuances like Debian directing users towards
nonfree repos and having marginally different set of accepted free
software license than the FSF. Does that mean you won't get away with
making users pull packages from F-Droid repos that also happen to serve
some FSDG-incompliant apps? I have no idea. Perhaps not? I just wanted
to express my concern just in case...


As to the problem of apps signed by someone else not being able
to access data of their previous versions, this is indeed an
unfortunate thing. While you discussed an interesting possibility of
there being an FSDG-compliant way to re-use authors-signed app builds,
why not go the opposite way?

IIUC, it was Google's unethically-motivated idea to restrict apps from
accessing their data this way. If this scheme is bad for users, perhaps
the best response long-term would be to fight it instead of complying
with it? You could move app validation into the package manager app and
then promote use of a single publicly-disclosed private key for signing.

Why something so drastic? No matter FSDG-compliance, having users run
binaries coming from untrusted environments seems like a veeeery
unwanted thing. In fact, being able to trust the binaries is among the
main benefits of using a (proper) package manager and a proper distro.

Unfortunately, the problem will not go away by itself. If you make the
hard decision of using a different signing key than the author, it will
create an inconvenience for users now but will make all subsequent
updates problem-free. If you don't, you automatically sacrifice
security&stability and risk having to make that decision anyway at some
later point, breaking all the installs users made by then.

Of course, serving both authors-signed and repo-signed versions of apps
in parallel and suggesting the latter to users who install an app for
the first time would also be a viable solution
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20210822/fb2ef507/attachment.asc>