Limit UserInfoCard to showing blocks within the past year

Image of the minimal example from above:

A discussion about this has been opened at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Addition_of_abusefilter-modify-restricted_right_to_EFMs.

There has not been an RFC.

In T405312#11204074, @Pppery wrote:

Unchecking "Unlock further protect options" has to do something; without it checked the "edit" and "move" protections are forced to be the same level.

Other information (browser name/version, screenshots, etc.):

The up and down buttons on the numeric fields are:

Another idea that has been discussed is the idea of being able to set a random failure rate for CAPTCHAs. This would only be used for highly accurate filters targeting severe abuse.

In T399351#10997090, @Pppery wrote:

I don't think the concept of CAPTCHA difficulty exists at all right now.

In T360592#10836006, @MusikAnimal wrote:

I think this is a misconception of the wikipage.content hook. It is not restricted to solely #mw-content-text. I've filed T394707: Do something about misconceptions of the wikipage.content hook.

In T377620#10244075, @TheDJ wrote:

Most of the times, scripts don't need this as they can simply be root relative. In the rare cases where it is required (URL constructor for instance), MediaWiki core scripts indeed use window.location or document.location.

In T195318#9784442, @Ahecht wrote:

I would vote for removing Rule 3 entirely. Skipping it for latin languages would solve the problem for users of latin languages, but not for users of non-latin languages. I would think that, except for the fallbacks explicitly laid out in fallbacks.json, showing the native name is preferable to a random name that happens to use the same script.

This problem is becoming worse and worse over time. Major place names in Manhattan are almost entirely Serbian at this point because name:sr-Latn is prioritized higher than the default name (which is English). The latinization code should probably not do anything if the default text is already entirely Latin characters.

I've been working on some user scripts that deal with custom signatures and it is a serious design flaw that there is nothing wrapping custom signatures and, more broadly, it's an issue that nothing indicates where a comment ends and the signature starts. This is especially the case given how many signatures are: