1) What, practically speaking, each anti-feature really is. For instance the description of the advertizing anti-feature says that no applications is known to have it, but the list of application with that anti-feature is not empty. We should check with upstream and fix the descriptions if we can.2) Look if Replicant is affected For instance Firefox exist in f-droid but it's not possible to run on Replicant. Still, Firefox should not be possible to install on Replicant because it can suggest non-free add ons.3) List and check well known suspicious applications such as firefox.4) List and check emulators, Parabola has a good reference on it here:https://wiki.parabola.nu/Emulator_licensing_issues

If no issues are to be found, Documentation should be made more clear.

If issues are to be found, F-droid will have to be fixed upstream, not to show any application with anti-features to Replicant users.We should also look which implementations would satisfy the guidelines requirements:

Should the filter be made automatic and not possible to disable.

Can the filter be a setting, and be enabled by default on Replicant.

Can upstream simply remove applications with anti-features?Having F-droid fixed upstream is desirable not to have to maintain a fork.

As I understand the "NonFreeNet" fits into the "informational" category:Free software applications that interact with websites like facebook are FSDG compliant, even if there is no free software implementation of the facebook website available that you can run on your own server.

Now the review of the Adds anti-feature:"Hungarian Rings for Android" is installable under Replicant. It's under the games category.At each startup it display a different image that looks like a splash screen. Unfortunately it's not a splash screen, it's an add.

Assuming the application is 100% free software, and that it's the same for other applications in that category, it's classed as an annoyance.

The anti-feature description should still be updated for sake of clarity.

GameBoid6 (Nintendo Gameboy Advance emulator): Some game boy advance emulators are in Parabola5, however GameBoid's description states: "To run this, you need a non-free BIOS file, which must be obtained elsewhere."

Nesoid (Nintendo NES emulator)[16]: In the menu, "Search ROMs" makes it go to a website with a search bar. TODO: Verify if that website has non-free roms, if so that is probably considered as promoting non-free software. The "ROM Gripper" buttons points to a google play page, which says "We're sorry, the requested URL was not found on this server"

Quest Player (Russian interactive fiction): is it an emulator? does it requires data?

Reicast2 (Dreamcast emulator): ITs description states "Bios/flash have to be on /sdcard/[...]" and it asks for BIOS files at startup. Howver it's in parabola5. According to [1], the GNU/Linux version is acceptable since it "BIOS" is "built-in free ReiOS uses as default to run the emulator". I don't know why the Android and GNU/Linux version differ. This should be investigated.

ScummVM22: In parabola23, Probably fine since some free software games exist.

Ask F-droid to implement a setting button to filter out applications with anti features.

Enable that filter by default when Replicant is detected.

Instead of sticking to that plan, I tried to evaluate the status quo, to avoid false positive.To avoid the long delay that is a consequence of that, why not instead:

Stick to the plan and filter out all anti-features, even if some of the filtered application do respect the GNU free system distributions guidelines

Evaluate the remaining applications to find which ones still don't respect the GNU free system distributions guidelines. This means looking at suspicious applications such as emulators. Then submit patches to the fdroid-data repository, to tag each of such applications with either Non free Addons, Non free Dependencies, or other relative anti-feature.

Then in a second time, the false-positives due to the filter of all anti-features could be looked into.

Regarding the tracking anti-feature: I only found the "No Malware" section in the FSDG guidelines and it only states that the distro must not contain spyware. The F-Droid anti-feature definition is actually more elaborate and clear than the FSDG definition in this regard.

So I guess apps with the tracking anti-feature need to be hidden, too?This would hide the Wikipedia app, among a few others.

It is also not always clear with these anti-feature definitions in F-Droid if only the upstream version is meant and the anti-feature was actually removed in the F-Droid version.

There are many apps that embed a webview for displaying websites. Most of these have very likely Javascript enabled in the webview. The default browser that is shipped with Replicant also has Javascript enabled. I'm not aware of a plugin that can be used to selectively allow Javascript and that works with the webview engine.

I'm not sure if it would be enough to advise users on the website or the wiki to disable Javascript by default and only enable it on pages they trust to serve free Javascript without spyware. Without too much effort, it would probably be possible for us to at least disable Javascript by default in the default browser and educate users about nonfree Javascript that might run in other places like apps with embedded webview or Browsers installed from F-Droid.

I see the second task as almost solved. #1635 takes care of the NonFreeAssets anti-feature definition and there is an open upstream bug. The Ads, NonFreeNet and UpstreamNonFree anti-features are informational or annoyances, but don't violate FSDG.Looking at apps that have the Tracking anti-feature makes it look a bit harsh to classify them as spyware in general. But the specific behavior of these apps, that warrant the Tracking anti-feature marking, is spying on the user without the user's consent, so I think it is the right decision to hide these apps on Replicant, especially when additionally considering that Replicant has a focus on privacy and security.NonFreeAdd and NonFreeDep are not FSDG-compliant as apps with these anti-features either promote non-free software or even are only functional if non-free software is present on the device. Apps with these anti-features need to be hidden. #1782 took care of the NonFreeAdd definition.So when #1635 is resolved, I'd consider this task as solved.

The third task will be an ongoing process as F-Droid constantly adds new apps. I think the best way to handle this task would be to create a dedicated wiki page for F-Droid. F-Droid will behave differently on Replicant as elsewhere because non-FSDG-apps will be filtered and the F-Droid privileged extension is shipped with Replicant 6.0, so it would be good anyway to explain these differences on a wiki page and inform users about FSDG-related issues with F-Droid in general terms. The wiki page could be used to collect questionable apps like the emulators and categorize them there. The upstream status of F-Droid issues or merge requests in relation to specific apps can be documented there, too. Subtasks to this issue can still be opened to discuss certain cases before opening an upstream bug or merge request. The wiki page should also explain the review process to get more Replicant users involved.

The F-Droid wiki page should also describe in general terms without mentioning specific (non-FSDG-compliant) apps how apps can be manually downloaded from F-Droid and verified on a PC. If users end up downloading non-FSDG-compliant apps from F-Droid on their PC, they are at least reminded that they should verify the signature.

The merge request was merged but later reverted. So we are back to square one for the first task.

Such a change will only be merged if there is proper filtering support in F-Droid. The filter code was removed before a rewrite some years ago. While it is easily possible to add code that grays out apps that violate GNU FSDG, it is not easy to add code that filters apps before a list is generated in the view. There are various adapters like ListAdapter or ArrayAdapter where filter support needs to be added. From my understanding of the code, an app listing is currently generated by assigning space in the view, pointing a cursor to it and then assigning app data to it. So the list entry for the app in the view is already there before app data can be accessed and e.g. the anti-features can be checked.

In the subsequent discussion in the #fdroid-dev irc channel after the revert of the merge request, a different approach came up. This issue discusses the possibility to define custom repos as a ROM builder. I already commented in this issue and tried to explain how this could be useful for us. Feel free to add your thoughts there, too! The issue also details how this could be implemented.

Every F-Droid repo has an index.xml and index.jar. These files contain the index of all apps included in the repo and their metadata. The index is signed. It could be possible to host a repo, that is compliant with GNU FSDG, by only hosting these two index files. We could write a script that takes the current F-Droid repo index, removes all FSDG-violating apps and resigns the index. The client expects that all apps are available in a subfolder of the web root that hosts the index. So we need to test if it's possible to redirect all http requests for apps to the F-Droid server. Some rewrite rule with regex needs to be added to the webserver config.

I was told that it would take a very long time until the F-Droid folks would be able to accommodate us and host something like this for us. But in the #osuosl irc channel, I was assured that OSUOSL could host the index files and add the required Rewrite rules to the webserver config.

The only problem would be the filtering and signing of the index. I don't like the idea to do this on the server side. I wouldn't see security decreased if the signing happens on the same machines that build and sign the Replicant images. We could find a way to securely share the signing key (e.g. at the next meeting) and then regularly download the F-Droid index, run the script on it, sign it and upload it. We could even automate this with a (ana)cron job on our machines.