Clarify the NonFreeNet and Tracking antifeatures
Discussions have kept arising from the definition and application of the NonFreeNet and Tracking AntiFeature.
Problem Description
The current definitions are not fully clear about the full coverage of "software freedom" and "privacy breaching".
‘NonFreeNet’ - the application relies on computational services that are impossible to replace or that the replacement cannot be connected to without major changes to the app. (https://f-droid.org/en/docs/Build_Metadata_Reference/#AntiFeatures)
- It can be read as if the (whole) app would need to rely on it. So some app developers try to argue that "just a little" NonFreeNet activity should be considered ok. (Results range from merely "forgetting", over articulating to intend to hide the fact from f-droid users, to barefaced complete removal of the antifeature info from the metadata. #1611 (closed))
‘Tracking’ - the application tracks and reports your activity to somewhere without your consent. It’s commonly used for when developers obtain crash logs without the user’s consent, or when an app is useless without some kind of authentication.
- The use of the word "consent" in the current tracking definition is problematic, because we see it is used in attempts to sidestep the proper listing of AntiFeatures by hiding or only "enabling" them as "experimental features" or on request "press button to show or enable map/weather/..." etc. third-party plugin.
Related Discussion
Following the discussion at #1439 (comment 178624004) there seems to be some consensus.
- Introducing finer grained specific-feature privacy/software-freedom AntiFeatures would make things worse.
- It's better to make current definitions more clear.
- The presence of specific features warrant listing an antifeature for the app.
That's also in line to how the Pix-Art-Messenger's antifeature meta data got defined. https://github.com/kriztan/Pix-Art-Messenger/issues/304
Possible Solution
I prepared a merge request with clarified definitions:
- ‘Tracking’ - user or activity data is tracked or leaks, by default.
True if the app or a feature can not be used without requests to a data
collecting network service (regardless
if it is based on free software, or not). For example, activity based downloading
of weather data, maps, avatars etc. (data hosting and delivery services), or
uploading of crash logs etc.
- ‘NonFreeNet’ - the application contains feature that uses a non-free
network service which is impossible, or not easy to replace. Replacement
requires changes to the app or service. There is no simple configuration
option to point the app to a running instance of an alternative,
publicly available, self-hostable, free software server solution.
Is everything covered? Improvement ideas?