I haven't yet decided on any specific deadline or schedule for v4, but as there are multiple ideas for changes and various things to be implemented to v4 for when that time comes, and several small mentions in issues and discussions before regarding v4, it makes sense to create a new issue to discuss those ideas, plus any others regarding v4 that others might want to share, and to serve as a checklist for those ideas and things to be implemented. Feel free to share any ideas/thoughts you may have (but no pressure, and no solid commitment/promise yet either way; though anything listed is more likely to be implemented than not).

Auxiliary rules.

• Drop the "don't log" action from the auxiliary rules system in favour of just using the "suppress logging" option instead (See: Aux rules suggestion #334).
• v3->v4 migration process: When using the backup page to import auxiliary rules to v4 which were exported from v3 or earlier, auxiliary rules marked with the "don't log" action should have the "suppress logging" option/flag added and their action changed from "don't log" to "profile".

CAPTCHAs.

AFAICT, Google wants everyone to migrate their reCAPTCHA API keys to a "Google Cloud project" before the end of 2025, is aiming to phase out support for the invisible API of their reCAPTCHA service, and is encouraging everyone to migrate to their v3 API. Currently, CIDRAM supports their v2 and invisible APIs, but not their v3 API. See:

• Classic reCAPTCHA Gets a Modern Upgrade on Google Cloud
• Questions regarding new reCAPTCHA 2025 changes
• Google reCAPTCHA Evolves: Mandatory Migration by 2025

This raises some important questions:

• In CIDRAM's current state, will its reCAPTCHA integration still work correctly after 2025? (The above-linked documentation strongly suggests that it won't, but Google's plans, and the way that they approach those plans, may change between now and then, and I don't think we can really be entirely sure about that until the time comes, so we may need to just wait and see to know for sure).
• Should support for their v3 API be added? And if so, how much effort/work would be required to do so (and would that required effort/work be more worthwhile than simply dropping support for reCAPTCHA entirely in favour of using something else, e.g., HCaptcha, which CIDRAM also already fully supports, particularly when considering the apparent need to adopt "Google Cloud project" in order for reCAPTCHA's v3 API to work correctly, which mightn't be too palatable to those users which aren't familiar with "Google Cloud project" and merely wish to have access to reCAPTCHA, without the need for anything else related to "Google Cloud project" and when weighed against any potential negatives)? Frankly, I'm not intimitely familiar with "Google Cloud project" myself, so to properly integrate their v3 API, I'd likely need to do some reading and research into it myself, to become more familiar with it, which I can do easily enough, but.. if I don't need to, and there's no imperative to do so, I likely wouldn't, as there's always other things I'd prefer to spend my time on (and I suspect many CIDRAM users would feel the same way regarding their own time).
• Should support for their invisible and v2 APIs be deprecated and removed for CIDRAM v4 (considering that Google is encouraging everyone to adopt their v3 API, and from similar situations in ths past, suggests that Google is likely to end up killing everything older than their v3 API entirely at some point)?
• Given that HCaptcha works perfectly fine as is, and hasn't posed any problems with CIDRAM AFAIK, do we need reCAPTCHA anymore? But given putting all of one's eggs into the one basket is rarely a good idea.. if reCAPTCHA was ditched entirely, should I maybe roll our own in-built CAPTCHA system just for CIDRAM? (I've built CAPTCHA systems before, and in theory, they're easy enough to build.. but I'd avoided building one into CIDRAM directly in the past, mostly, because there are a bunch of features that come with a hosted CAPTCHA service that an in-built CAPTCHA feature lacking any such backed service would be unable to provide, like detailed analytics, user behavioural analysis like mouse movements and such, detailed tracking and connected dashboard, or.. a dedicated team focusing solely on improving said CAPTCHA service, as opposed to a single developer looking at an in-built CAPTCHA feature as being just another feature to maintain in the package as a whole, by necessity of available time, resource constraints, etc; like.. I could build one easily in a day or so, and it would, of course, work properly, but it likely wouldn't ever be quite as good as any provided by a dedicated, hosted service/platform).

So, considerations, and decisions to be made in that regard. Would be happy to hear how others feel about this.

Why I'm writing about this reCAPTCHA question in the ideas/checklist for v4 issue instead of in its own issue: It feels to me like one way or another, something is going to need to be deprecated somewhere, and that would be a backwards-incompatible change. As always, in adherence of semantic versioning, backwards-incompatible changes should signify, or be flagged for, a new major version number. In this case, v4.

• Remove support for reCAPTCHA.

That aside, other CAPTCHA-related changes:

• Merge the lockip and lockuser configuration directives into the one, with three available options provided:
• 1. Lock CAPTCHAs to the IP address of the user completing the CAPTCHA but not to the actual user.
• 2. Lock CAPTCHAs to the user completing the CAPTCHA as well as to their IP address.
• 3. Lock CAPTCHAs to the user completing the CAPTCHA but not to their IP address.

Having these two configuration directives be separate, and as booleans, implies four different potential states (boolean = true or false = two states x two different directives = four different potential states). But, because the value of lockip is ignored when lockuser is set to false, in reality, there are only three different potential states. Thus, merging the two configuration directives and providing clearer, more exact descriptions for those states makes sense. (I've been wanting to do this for a long time now, but again.. a backwards-incompatible change, so something to be earmarked for v4). Planning on provided said three options as selectable radio options at the configuration page.

• Better descriptions and hinting for the newly merged configuration directive. Currently, the two available configuration directives just state "Lock CAPTCHA to IPs?" and "Lock CAPTCHA to users?" respectively, which.. to someone without any insider knowledge, someone which doesn't already know what that means exactly, isn't the most descriptive, precise way to state what they actually do. After being merged, better descriptions and hinting should be applied to fix that.
• Split CAPTCHA statistics by service and endpoint. Currently, statistics can be enabled for CAPTCHAs as a whole (how many instances passed, failed, etc), but they aren't separated by the service/endpoint responsible.
• Add support for tracking CAPTCHAs served but not attempted to the statistics.
• Add support for Friendly Captcha.
• Add support for Cloudflare Turnstile.
• Ensure changes to the supported CAPTCHA systems properly align with modules and the auxiliary rules system (e.g., compatibility with enactOptions and various flags/options provided for auxiliary rules).

Execution stages.

• Add ban check ("BanCheck") as its own execution stage. Currently, the point in the execution chain responsible for checking whether an IP address has been banned by IP tracking is configurable as IP tracking ("Tracking"). To make that point in the execution chain distinct, from a configuration perspective, from the point in the execution chain where the total infractions for a request are tallied and applied to the IP tracking cache (which currently is also configurable as IP tracking), it should be given its own execution stage. This would allow users to enable one while disabling the other (which isn't currently possible; currently, either both are enabled or both are disabled).
• Add processing the email trigger notifications queue ("TriggerNotifications") as its own execution stage. Currently, the point in the execution chain responsible for processing the email trigger notifications queue isn't configurable at all (i.e., can't be explicitly turned on or off, and instead currently always executes; though without any actual effect if the trigger notifications feature is disabled as a whole). TriggerNotifications already exists for debugging purposes, but doesn't yet exist in the configuration. Adding it to the configuration was delayed to avoid potential backwards-compatibility problems which could've arisen if added prior to v4.

Response status codes.

Currently, the status code returned when a request is blocked can be controlled via http_response_header_code, which can be overridden by ban_override when the requesting IP address has been banned by IP tracking, can be overridden by features like rate limiting when said features come into effect, or by auxiliary rules if a rule which uses the "HTTP status code override" option is triggered.

Currently, http_response_header_code applies to blocked requests as a whole, but doesn't provide a means of controlling the status code returned in a granular way, to return a different status code when specific shorthand words were used by the signatures responsible for the block event. An example of where controlling the status code returned in a granular way would be useful would be in being able to return 451 for the "Legal" shorthand word while continuing to return something else (e.g., 403, 410, 503) for anything else. This should, of course, exempt shorthand words like "RL" and "Conflict", the former which should always return 429 and the latter which can be controlled via conflict_response.

As the "Banned" shorthand word isn't used by any signatures, but is used internally to signify when the requesting IP address has been banned by IP tracking, it's effectively controlled via ban_override.

• Modify http_response_header_code to allow the status code returned when a request is blocked to be controlled in a granular way (i.e., block events for bans, block events involving "legal" block reason signatures, and default block events).
• By accounting for block events for bans, ban_override would be no longer needed, and could be deprecated/removed.
• Investigate possible solutions for more granular control of returned status codes.

Also considering whether I should extend the available options to allow it to optionally provide different status codes when blocked due to specific modules (e.g., when something is blocked by the protocol blocker module, to be able to serve a 426 Upgrade header to the client, which isn't anything particularly important, but it's an idea).

Minimum required PHP version.

Note: Decided to postpone an increase of the minimum required PHP version until at least >= v5.

None of the ideas or checklist items mentioned thus far necessitate increasing the minimum required PHP version, and so, could all be implemented while still retaining a minimum required PHP version of 7.2. However, as per PHP's own Supported Versions page, the oldest version of PHP which isn't already dead/EoL at the time of creating this issue is 8.1. Does that mean we need to increase the minimum required PHP version to 8.1? No, it doesn't. But should we? Well.. For that particularly reason alone, not really, no. Ensuring that users stay up to-date with currently supported PHP versions, as much as doing so is recommended for security reasons, is not our responsibility, nor CIDRAM's responsibility.

However, keeping in mind that it's better that increasing the minimum required PHP version occurs only when a new major version is released, if we don't do it for v4, it likely won't happen until a future v5 is release, if/when that ever happens. What that means is that it should probably be considered whether we might need a version of PHP newer than 7.2 at some point during the v4 life cycle. Do I think we will be needing a newer version during the v4 life cycle..? Honestly, I've no idea. Maybe, maybe not. What I do know is that none of the ideas put forward thus far require it, so unless that changes, we should be fine sticking with 7.2 for now. We'll see how that goes, I guess.

PHP versions available to be used within GitHub workflows still go back as far as 5.4, so no problem in that particular regard.

If we were to increase the minimum required PHP version (and assuming it's at least >= 8.0):

• Implement "union types" for method parameter and return type declarations (not available for versions < 8; won't affect CIDRAM from a user perspective, but should make type-safety and the semantic accuracy of method signatures more rigorous; low priority, but should be implemented if the opportunity to do so arises, i.e., if the minimum required PHP version allows for it).
• Investigate potential refactoring and other potential improvements due to newly available features, syntax, etc as a result of increasing the minimum required version and implement wherever appropriate (low priority).

Terminology.

Some of the terminology used by CIDRAM could be simplified, to make it more intuitive for users, like writing "reset signatures count to zero" instead of "greylist". I've contemplated that before, but considering the 40+ languages which CIDRAM supports, and that all the translations for all those languages would need to be updated to reflect the changes if any terminology was to be changed, plus considering that on a subject like terminology used, there's a strong likelihood of continually find more and more things to change, the scope easily spiraling out of control very quickly, it's an idea I've not brought up before nor put too much weight on (because it feels like the kind of thing which could end up taking up a lot more time to complete than initially appears to be the case). I think, in the end, such an idea could definitely serve to improve CIDRAM, but I'm not sure if the effort is worth the payout. Briefly mentioning here anyway, in case anyone wanted to give their input on that, and seeing as such changes would generally be backwards-incompatible changes, and thus relevant to this issue (assuming those changes were to happen, anyway).

Documentation.

• The process to update to the new major version needs to be fully documented.
• All translations for the new documentation completed.