[Policy] Deprecate Ban module

Removing a module from core requires the signoff of the subsystem maintainer when there is one, as well as all the committer roles.

The committer team recently reviewed our scoring exercise on all core modules, and there was not clear consensus to remove Ban, so it needs to be discussed further (both by the committers, and with input from the community).

Thanks!

Just for posterity we're six weeks from the 15 year anniversary of me first opening an issue to try to remove this from core #228594: UMN Usability: split access rules into an optional module → .

From a framework manager point of view, I'm happy for it to be moved to contrib. There are a number of contrib solutions, and larger sites will using something at the WAF/CDN layer. Not removing the tag as giving others a chance to chime in.

There are a number of contrib solutions, and larger sites will using something at the WAF/CDN layer.

Totally agreed on this. In my point of view, from the perspective of webmaster banning an IP address is not a webmaster task but rather the task of network administration of the project, which as you mentioned should be done at the WAF or CDN level. The task itself, with today's technology could be easily done and resolved when appropriate credentials are provided.
In addition, from the security stand point it is best suited to prevent the malicious/intruder traffic stopped at the edge not the production environment. Also there are more means to mitigate bad actors.
I suggest, Drupal as a content management system be more focused on providing modules that offer best digital experience.

I was thinking of introducing a Ban entity to make it more extendable. The current ban_ip table has two fields iid(unique ID for IP addresses) and ip. -- It's a simple module, unlikely to have many issues reported as other core modules. Inactivity makes sense to me.

There are a number of contrib solutions

Yes, there are related contrib modules, but I prefer none of them. E.g., I hope to see a reason why the IP is banned. autoban, advban etc. can not show me that.

and larger sites will using something at the WAF/CDN layer.

There are small sites built with Drupal without WAF or CDN, e.g. some personal blog sites.

In short, I hope it can adopt entity, instead of being removed.

Regarding the proposal in #39, that could also be done if/when the module is moved to contrib. :)

The two obvious alternatives in contrib appear to be in good shape, both with releases made this year
https://www.drupal.org/project/autoban →
https://www.drupal.org/project/advban →

Lets just go ahead and do this? Removing the framework manager review tag as @catch opened this issue and @larowlan chimed in at #1570102-37: [Policy] Deprecate Ban module in Drupal 10 and move it to contrib for Drupal 11 →

Lets not be too eager here Roy!

See #37

Removing versions from the title. They can be added back if this is approved.

I think we should revisit this, again, with project browser + recipes getting closer to stable and Drupal CMS/starshot coming through too.

There could be a recipe, either just generally in contrib or included with Drupal CMS, for anti-spam/anti-abuse. For me, the 'silent captcha' modules like honeypot and/or antibot are more important for this than IP banning, but it could include ban module or one of the contrib alternatives instead as well.

That way it would be one less module when you install core, and Drupal CMS and recipes seems like a good fit for anti-spam/anti-abuse modules where there are big benefits to being able to swap in and out (and combine) different approaches. It would not take 16 years to move something in or out of starshot as it has here.

+1 to #45. I opened https://github.com/phenaproxima/starshot-prototype/issues/98 for visibility there as well.

Drupal CMS and recipes seems like a good fit for anti-spam/anti-abuse modules where there are big benefits to being able to swap in and out (and combine) different approaches. It would not take 16 years to move something in or out of starshot as it has here.

Fully agreed with this. Updated the suggested version numbers in the issue summary to reality. While the core committers did not agree yet in 2023 on this, I think the project browser + recipes solution changes the situation significantly for modules like this.