Skip to content

new anti feature IndirectAF

I request the introduction of a new anti feature. It is similar to KnownVuln bit not covered by the description in https://f-droid.org/wiki/page/AntiFeature:KnownVuln

Generally security flaws are not covered by the anti features, even though completely confirm apps ARE being rejected simply because of security issues. Example: rfp#253 (closed) ( I know that, because I was the one who found the security issues)

Description:

The new anti feature shall be applied if an app has one or more of the following:

  • secret functionality
  • undocumented functionality (non-trivial functions that are not in the app description)
  • Easter eggs
  • functions that are different or even clearly opposing the expectable functionality
  • hard-coded links (not user generated content) to potentially undesirable services
  • hard-coded censorship of unassumingly free online resources (like a browser that secretly doesn't open certain domains or slows them down)

Where the above is both:

  • not a bug (can be judged from a bug-report and the developers willingness to fix it)
  • unavoidable for normal users even if only a small group of users or only small parts of the app

And where the above results in one or more of the following anti features:

  • Ads
  • Tracking
  • NonFreeNet
  • a privacy or security flaw by forwarding to a Datenkrake or a malicious website or web-service
  • the exposure to privacy or security flaws that Google would not recognise as such (and therefore they are not prevented by Android, which is mostly made by Google)
  • the download of more data that expected ( like loading a video in a micro-blogging app )
  • has the ability to increase the view counter on YouTube Videos
  • has the ability to increase the like counter on Facebook pages
  • has the ability to increase the view counter in Ad Networks
  • other abilities that could result in the indirect financial advantage of some one else, without the consent of the user of the app
  • imposes a substantial risk, on being prosecuted in places where connections to YouTube are not allowed (employers, corporate networks, some countries, ....)

Name of the new AF:

I've created a poll here https://framadate.org/kpwQNVqyU68mtzRx please vote!

Alternative names for the new anti feature could be:

  • IndirectAF
  • PotentiallyUndesiredBahaviour
  • MalicoiusEasterEgg
  • UndesirableSecret
  • Censorship ... any other ideas?

Example:

Assuming an app would do the following:

  • hard code a link to YouTube (random example: here)
  • open this link with an intent but filter it only for some users with specific expectable inputs (random example: here )
  • doing this without asking the user

While the youtube link could be opened in the Tor Browser or in Newpipe, it could also be opened in the default browser. This is not a user choice but an unrelated detail of which and how many apps the user has installed and how the default apps are configured.

This can result in one or more of these:

  • exposing the IP of the user to Youtube
  • enabling more tracking depending on browser settings
  • more tracking it the user has used any google product with that browser
  • unwanted exposure to Ads (example: https://www.youtube.com/watch?v=dQw4w9WgXcQ )
  • unwanted raise of income for the uploader of the video
  • unwanted increase of customers for the creator of the ad
  • unwanted vomiting of the app user, if the video was a Rick Astley song (example: https://www.youtube.com/watch?v=dQw4w9WgXcQ )
  • usage of non free services
  • usage of 250 MB of data volume on the app user

Counter Examples:

  • F-Droid client, contains youtube links, but they are user generated content and also clearly declared in 'video'. no anti-feature.
  • SimpleEmail, contains links in user generated content and asks specically before opening any of them. no anti-feature.
  • NewPipe: Is specifically made to load youtube videos and has the anti-feature declared for it. no new anti-feature.
Edited by Andreas Redmer

Merge request reports