> One FOSS organization, for example, requires all legal correspondence to be submitted by postal mail in the national language and citing local law. Most complaints evaporate once asked to comply.
TFA goes: A window for response (commonly 14 days) is offered, unless unfeasible due to seriousness and time restraints of the request itself. If the developer disputes the claim and provides supporting information (e.g. license, public domain status, fair use justification), the claim is reviewed.
As someone who has had multiple FOSS projects take down by companies / app stores (happens when we go viral in some country), DDoS'd by rouge actors (thanks for saving our bacon, Cloudflare!), visits from law enforcement etc; F-Droid's post on "appeals process" comes as a surprise. Here's the email I received from them:
Dear The Rethink DNS Authors,
The F-Droid platform has received an official order from Roskomnadzor (RKN), Russia's Federal Service for Supervision of Communications, IT, and Mass Media, regarding Rethink (Registry Entry #3133609-РИ) https://f-droid.org/ru/packages/com.celzero.bravedns/
...
F-Droid took technical measures to block your website app page for the Russian site visitors to avoid the risk of limited access to F-Droid as a whole. For further queries or concerns, contact legal@f-droid.org.
Thank you for your cooperation.
Nothing in there informs me that I had the opportunity to appeal.
TFA frames this all as recent and ongoing learnings and changes at F-Droid. Given the notability of your project (kudos and thanks), perhaps they'd appreciate your input.
The folks who run F-Droid are very welcoming, no doubt. But the email asked us to direct queries to legal at f-droid.org, and for us, legal is something we have no time/energy/capability to pursue (unless there's explicit offer of help, viz. "window for response", that I am hearing only for the first-time and from this blog post).
> notability of your project (kudos and thanks)
Rethink DNS + Firewall? Barely at 10% of installs as the most popular project in the domain (NetGuard), but thanks! (:
...While I have your ear: IME ReThink DNS often runs into bootstrapping problems since 1) preconfigured DNS servers are referenced by hostname, not IP 2) I can't find a way to separately configure server address and TLS name (making it impossible to configure DoH/DoT servers via IP).
So users often run into "catch 22" where they need existing DNS to resolve their DNS server... When roaming it may work fine for a bit until the local cache drops it, and so on.
Allowing to separately configure TLS hostname for TLS-enabled protocols, and having a preseeded list of IPs for bundled provider endpoints, would mean ReThink DNS could work reliably even in absense of existing DNS.
> ReThink DNS often runs into bootstrapping problems
Rethink, the Android app, has a preset list of 5 bootstrap resolvers that you can choose from Configure -> Network -> Fallback DNS. If set to None or System (the default), Android-designated DNS upstream is used (or Quad9 plain DNS is used if it goes missing). You can also set Fallback DNS to Cloudflare (one.one.one.one), Google (dns.google), Quad9 (dns11.quad9.net), or Rethink (zero.rethinkdns.com). Unlike None / System, these use DoH.
> can't find a way to separately configure ... TLS name
> having a preseeded list of IPs for bundled provider endpoints
This capability exists though we don't expose it via the UI. For instance, ALL preset DNS upstreams (DoH, DoT, ODoH, DNSCrypt), including Fallback DNS, that ship with Rethink, are seeded with IPs at compile time. Given bootstrap DNS (aka Fallback DNS) is already DoH + seeded, the "catch 22" scenario you outline shouldn't come to pass. If it has, then that's a bug we need to fix.
I typically get a takedown notice a couple times a week, usually from my registrar (Namecheap) or from Netcraft, about 100 so far.
I keep a public (transparent) list of takedowns, on a public repo on GitHub. The commit messages are the logs. [0]
I have a way to dispute: raise a GitHub issue. I've only had two people dispute: one was legit, and I unblocked him, and the other ran a WordPress site which he didn't know was compromised. I did not unblock him. [1]
Please don't judge me harshly for honoring the takedowns immediately, but I do so because the remedy is simple: register your own domain, and don't rely on my nip.io / sslip.io service (which maps IP addresses to hostnames as a convenience for developers, e.g. 127.0.0.1.nip.io → 127.0.0.1).
Dealing with takedown requests is the least pleasant aspect of running FOSS project. I want to spend my free time coding, not blocking phishers, scammers, and grifters.
This seems like a well balanced approach. I do love the abuse mitigation measures in place to dissuade casually malicious actors. The fact that providing evidence itself is a deterrent just goes to show how ill intentioned most of them are.
The entire concept of a "takedown request" is a compromise solution. Platforms would ideally like to be a public square, where third parties can say whatever they want and the platform doesn't have to do much about it. Copyright holders, revenge porn victims, etc. would prefer to hold the platforms strictly liable, because on the Internet it's extremely hard to actually find the third parties. So in a variety of contexts we've found it's useful to meet in the middle: platforms are exempt from liability, but in return they have to process takedown requests, unless the third party challenges the takedown and makes themselves available for possible legal proceedings.
It doesn't, but platforms basically do everything they can to claim the various common-carrier liability shields in DMCA-like laws. In the U.S. that means they forward the takedown request to whomever generated the content, and in theory should allow that generator to comply, or publish a counterclaim.
The whole system falls on the floor though when the common carriers aren't, and have low quality processes that don't actually enable the counterclaim half of this process.
Don't be fooled. These so called low quality processes are designed by large corporations in order to abuse their positions and retain control over all content being shown. The providers have no interest in providing legal protections to their small content creators. They want to focus on pleasing the big players.
> One FOSS organization, for example, requires all legal correspondence to be submitted by postal mail in the national language and citing local law. Most complaints evaporate once asked to comply.
Pure gold.
TFA goes: A window for response (commonly 14 days) is offered, unless unfeasible due to seriousness and time restraints of the request itself. If the developer disputes the claim and provides supporting information (e.g. license, public domain status, fair use justification), the claim is reviewed.
As someone who has had multiple FOSS projects take down by companies / app stores (happens when we go viral in some country), DDoS'd by rouge actors (thanks for saving our bacon, Cloudflare!), visits from law enforcement etc; F-Droid's post on "appeals process" comes as a surprise. Here's the email I received from them:
Nothing in there informs me that I had the opportunity to appeal.How recently was this experience?
TFA frames this all as recent and ongoing learnings and changes at F-Droid. Given the notability of your project (kudos and thanks), perhaps they'd appreciate your input.
> How recently was this experience
The email I shared here? 27th Aug 2025.
> perhaps they'd appreciate your input
The folks who run F-Droid are very welcoming, no doubt. But the email asked us to direct queries to legal at f-droid.org, and for us, legal is something we have no time/energy/capability to pursue (unless there's explicit offer of help, viz. "window for response", that I am hearing only for the first-time and from this blog post).
> notability of your project (kudos and thanks)
Rethink DNS + Firewall? Barely at 10% of installs as the most popular project in the domain (NetGuard), but thanks! (:
Cheers! 10% is nothing to scoff at!
...While I have your ear: IME ReThink DNS often runs into bootstrapping problems since 1) preconfigured DNS servers are referenced by hostname, not IP 2) I can't find a way to separately configure server address and TLS name (making it impossible to configure DoH/DoT servers via IP).
So users often run into "catch 22" where they need existing DNS to resolve their DNS server... When roaming it may work fine for a bit until the local cache drops it, and so on.
Allowing to separately configure TLS hostname for TLS-enabled protocols, and having a preseeded list of IPs for bundled provider endpoints, would mean ReThink DNS could work reliably even in absense of existing DNS.
cf tls_auth_name for stubby. https://dnsprivacy.org/dns_privacy_daemon_-_stubby/configuri...
> ReThink DNS often runs into bootstrapping problems
Rethink, the Android app, has a preset list of 5 bootstrap resolvers that you can choose from Configure -> Network -> Fallback DNS. If set to None or System (the default), Android-designated DNS upstream is used (or Quad9 plain DNS is used if it goes missing). You can also set Fallback DNS to Cloudflare (one.one.one.one), Google (dns.google), Quad9 (dns11.quad9.net), or Rethink (zero.rethinkdns.com). Unlike None / System, these use DoH.
> can't find a way to separately configure ... TLS name
You mean, send a different SNI? As in, for domain fronting? If so: https://github.com/celzero/firestack/issues/18
> having a preseeded list of IPs for bundled provider endpoints
This capability exists though we don't expose it via the UI. For instance, ALL preset DNS upstreams (DoH, DoT, ODoH, DNSCrypt), including Fallback DNS, that ship with Rethink, are seeded with IPs at compile time. Given bootstrap DNS (aka Fallback DNS) is already DoH + seeded, the "catch 22" scenario you outline shouldn't come to pass. If it has, then that's a bug we need to fix.
Maybe depends on whether the national authority (RKN here) allows appeals from either f-droid or you?
> Maybe depends...
Of course, but you'd think F-Droid would let you know in that same email?
I typically get a takedown notice a couple times a week, usually from my registrar (Namecheap) or from Netcraft, about 100 so far.
I keep a public (transparent) list of takedowns, on a public repo on GitHub. The commit messages are the logs. [0]
I have a way to dispute: raise a GitHub issue. I've only had two people dispute: one was legit, and I unblocked him, and the other ran a WordPress site which he didn't know was compromised. I did not unblock him. [1]
Please don't judge me harshly for honoring the takedowns immediately, but I do so because the remedy is simple: register your own domain, and don't rely on my nip.io / sslip.io service (which maps IP addresses to hostnames as a convenience for developers, e.g. 127.0.0.1.nip.io → 127.0.0.1).
Dealing with takedown requests is the least pleasant aspect of running FOSS project. I want to spend my free time coding, not blocking phishers, scammers, and grifters.
[0] https://github.com/cunnie/sslip.io-blocklist [1] https://github.com/cunnie/sslip.io/issues/100
Thanks a lot my friend! You saved my day in reminding me to include blocklists on my server respectively block more aggressively.
I got so much inbound traffic from malicious actors, my fail2ban blocking needs serious attention.
Thanks, mate!
For me, SSH based password guessing attempts decreased by roughly 100% since I switched to a non-standard port.
This seems like a well balanced approach. I do love the abuse mitigation measures in place to dissuade casually malicious actors. The fact that providing evidence itself is a deterrent just goes to show how ill intentioned most of them are.
How does it make sense to ask an app developer to appeal on behalf of a platform they have zero control over?
The entire concept of a "takedown request" is a compromise solution. Platforms would ideally like to be a public square, where third parties can say whatever they want and the platform doesn't have to do much about it. Copyright holders, revenge porn victims, etc. would prefer to hold the platforms strictly liable, because on the Internet it's extremely hard to actually find the third parties. So in a variety of contexts we've found it's useful to meet in the middle: platforms are exempt from liability, but in return they have to process takedown requests, unless the third party challenges the takedown and makes themselves available for possible legal proceedings.
That doesn't really apply to a platform that can only be published to by the platform itself, with no external publishers, as far as I know.
It doesn't, but platforms basically do everything they can to claim the various common-carrier liability shields in DMCA-like laws. In the U.S. that means they forward the takedown request to whomever generated the content, and in theory should allow that generator to comply, or publish a counterclaim.
The whole system falls on the floor though when the common carriers aren't, and have low quality processes that don't actually enable the counterclaim half of this process.
Don't be fooled. These so called low quality processes are designed by large corporations in order to abuse their positions and retain control over all content being shown. The providers have no interest in providing legal protections to their small content creators. They want to focus on pleasing the big players.