Some apps re-route requests for opening websites. They don’t cause network traffic themselves, but they redirect users from or to specific non-free websites when following a web-link.
Nitterizeme: re-routes twitter-links to a configurable nitter instance and youtube-links to a configurable invidious instance. While Nitter and Invidious are free-software they’re still basically an alternative front-end for non-free web-sites. So if twitter goes down, or should twitter decides to block nitter instances, nitter would be defunct. So there’s a very strong dependency here. Same goes for the relation between invidious and youtube.
NeoLinker (formerly Netscope) redirects web-links to web-sites which perform services like web-search, virus-scans, etc. Some of those web-sites are free others however are non-free (virus total, gibiru). So this app itself does not cause any network-connections but is (suggesting) to redirect web-links to of non-free websites.
Initially I was under the impression I should get those apps tagged with Non-Free Network Services anti-feature, because these apps integrate non-free websites into user experience. However app-authors and some members of our team don’t seem to agree. So naturally I’m interested in, whether our users would expect these apps to be tagged with Non-Free Network Services anti-feature or not, I know I would.
This Anti-Feature is applied to apps that promote or depend entirely on a non-Free network service.
I don’t think we’ll get far with arguing over “depends entirely”. because, errr, when youtube.com stops existing, you don’t need to rewrite any youtube links anymore. The app is not needed anymore.
So thinking about the “promotes” nonfree services aspect might be more interesting (and I don’t have any answer to that currently).
My intuitive reation though was, that no, the app does the opposite it raises awareness about proprietary services, the included tracking, that we can and should build alternatives and until that happens we can at least avoid visiting the services directly and proxy through a more privacy preserving foss frontend for it.
But I can see this argument working in the other direction as well.
It promotes the propritary service, and depends on the proprietary service.
If someone is deplatformed from Youtube or Twitter for speaking out, then by serving content from that service you are promoting that deplatforming by serving other proprietary content from that service, you are also implicitly promoting the agenda of the proprietary service.
It goes without saying therefore, that the proxy service (nitter, invidious), the people who publish content on the proprietary service and the users of the app are all “entirely dependant” on the whim of that service, which is difficult to reproduce (or impossible to reproduce if closed source, which they both are).
I agree that invidious and nitter are dependent and also promoting nonfree services.
I disagree with your conclusion that therefore NitterizeMe is promoting these services. The only thing that the app does is explixitly promoting a free service over a nonfree one. If you never use the nonfree-one you’ll never need nitterizeme in the first place. And if you were you are now using a less worse option than before.
It’s promoting the service because it is furthering the reach of the service, and the people on that service, thus creating an extra incentive for people to use the difficult-to-reproduce (non-free/monopoly/permissioned) service. The content creator knows that FOSS and privacy enthusiasts might still be able to access their content by publishing on that difficult-to-reproduce (non-free/monopoly/permissioned) service.
It shouldn’t concern us whether they are raising awareness for FOSS, or are a lesser of two evils.
A genuine FOSS alternative might be a torrent-like service that enables people to serve the content of their peers that they really love to other peers that successfully fulfil a FOSS captcha or answer a question related to an advertised product or service, or offer a token to access the content.
Since some could miss the point, NeoLinker actively promotes android/Share functionality and searX.
Gibiru & VirusTotal come after, at end-choices, because (like xda, @relan) they don’t have foss alternatives yet(?) but do provide true and friendly supplements (until further notice ? Issues · PRISM Break / PRISM Break · GitLab).
That’s good, and could be listed as positive features of the app, but doesn’t change the fact that an app might promote and further the reach of difficult-to-reproduce, non-free, monopoly and highly centralised and permissioned services.
While I see your point, @relan. If it is removed then a new anti-feature needs to be created for “Uses a difficult-to-reproduce network service”.
From the wiki: rel[ies] on a networking service that is not (by our knowledge) run or easy to reproduce with free software.
Also for the case of Newpipe for example, another anti-feature should be created “Uses monopoly-like services” that relates to using a service that is considered to have a monopoly… try using vimeo with Goo Javascript disabled.
EDIT: Also another anti-feature: “May violate service agreement terms of a proprietary service” (in this case the service agreement terms of Google) and thus may stop working at any moment, or experience intermittent service outages.
My understanding and enforcing of this AF (so far) was linked to the bolded part:
‘NonFreeNet’ - the application contains a feature that uses a non-free network service which is impossible, or not easy to replace. Replacement requires changes to the app or service. This antifeature would not apply, if there is a simple configuration option that allows pointing the app to a running instance of an alternative, publicly available, self-hostable, free software server solution.
So instead of NonFreeNet maybe name it SiloNet or LockedNet
Yes LockedNet relates to what you made bold, @Licaon_Kter.
If an apps default purpose is to use Youtube then the anti-features I outlined above ought to apply. For example, if an app contains adverts or collects data, then it attracts those anti-feature, even if in the settings one can switch on or off those things.
Therefore the same methodology ought to apply to the default setting of an app that MayViolateTerms, uses a MonopolyNet or uses a NetworkNotEasyToReproduce, for example.
Terms of the Proprietary Service where content is being scraped from. Thus the user might be inadvertantly breaking Service Agreements, licenses or laws in the country where the Proprietary Service has such and may be held liable. Also might not be reliable as the Proprietary Service may find ways to break the loopholes that allow the scraping of the content.
There’s fixing and then there’s awareness. Highlighting the anti-features to me, is about awareness and awareness is important. TBH this anti-feature, would literally only exist for Youtube scrapers. There exists viable alternatives to basically everything else Goo does.
Woah, this went quite a bit further than expected. I don’t think we should split NonFreeNet up. Increasing granularity of anti-features will unnecessarily increase the amount brain-power we’ll need to manage all of that. Actually we already figured out a better way to deal with making AF-assignments more precise without any need to constantly update our AF policy: Anti-Feature Maintainer-Notes as structured text (fdroidserver#683). (If someone feels very strongly about renaming NonFreeNet to something better suited, please start a separate thread about that.)
So summarizing all of the above my personal takeaways are:
NitterizeMe: We shouldn’t enforce NonFreeNet, because it raises awareness and pushes back against huge SaaS silos, even thou there’s an indirect dependency on non-free network services.
NeoLinker: Still a bit unclear. It covers a couple of use-cases and some of them clearly depend non-free network services, others don’t. I couldn’t find any precedent on how we dealt with that in the past either. So having some entirely free software use-cases qualifies apps to not get tagged with NonFreeNet?
If defualt is Twitter I’d keep the AF but I’d consider Twitter fairly easy-to-reproduce with Fediverse. Having said that, I don’t think Fediverse is fully open as the backend required reporting and/or permission of Cloudflare, if my memory serves.
I don’t know what that is but if the default setting is to use non-free and difficult-to-reproduce then I’d definately use the AF.
I’m not familiar with Neo linker but to your point about browsers that default to Google or Bing (even DDG), yes I’d say that you can apply the NonFreeNet and the app description would explain why they have that AF and how a user can opt to switch to other searches like searx (or ActivityPub hashes) etc.
The AF listing is about general awareness, in my view…
