It'd be probably useful if we logged somewhere when a throttle override exemption has been applied (ie the override allowed an action that might not have been otherwise allowed)
We don't have this with the current implementation, has this ever been a problem?
A quick braindump on privacy. Basically everything is relateable to the performer. If we make it relateable to the exemption (which itself has the ip range attached to it) too, we effectively relate the performer to their ip address. That's especially a problem if we're logging each edit, page move, ... that would have triggered an captcha (T174225) or would have been blocked if it wasn't for ThrottleOverride. I wonder how much information the log message should contain:
- "User account EddieGP was created, bypassing the account creation throttle because of the exemption for 220.127.116.11/24"
- "Some account was created, bypassing the account creation throttle because of an exemption for 18.104.22.168/24."
- "User account EddieGP was created, bypassing the account creation throttle because of some exemption"
- "Some user account was created bypassing the account creation throttle because of some exemption".
I think #1 is really something we can't publish. Both #2 and #3 still don't effectively vanish the privacy concerns, thinking of smaller wikis with few account creations and/or few throttle exemptions. A message not problematic in the sense of privacy would be something like #4. Then again the most useful of these messages is #1, while the usefulness of #2 and #3 is drastically reduced and #4 is basically useless. So imho, if there is such a log, it'd have to be like #1 and as protected as the checkuser log.
The implementation would be easy, similar to T62421, create a log entry in ThrottleOverrideHooks::onPingLimiter whenever exempting an action.
Famous last words. Not as simple as I thought: It's easy to identify whether ThrottleOverride returned "bypass this throttle, there's an exemption for it". This is what the patch does.
However, this does not take into account whether the action would otherwise have been blocked. So for the account creation throttle, we'd not only log the 7th, 8th attempt to create a user account from an ip (which would have hit the account creation throttle (maximum 6), thus blocking the account creation) but also the 1st, 2nd, 3rd user accounts created (which would not have hit the account creation throttle). This may lead to a lot of logspam, as it'd log each and every edit done from any ip that is within an exemption range.
The problem is that the evaluation whether an throttle was hit doesn't take place at all if there's an exemption found. That evaluation comes after the hook was run. When the hook identifies the situation "I've got an exemption for this.", it sets $result accordingly and returns false, meaning "Do not continue the evalution." This is senseful, as the evaluation "would a throttle have been hit if there wouldn't have been any exemption?" isn't necessary when we already know there is an exemption and thus any throttle that might be hit won't be applied anyway.