Gabriele, indicated we shouldn't use the current methodology unless they have very
good alternatives - but the same applies to stopping it.
We don't have the capacity to handle a big bulk increase in pending changes as
proposed by gbfv on en-wiki and presumably others as well - and making very short-length
blocks on proxies would require a major increase in Steward time, which a quick review of
the average myriad steward backlogs indicates is not really a resource in sufficient
supply to be profligate with.
Others have proposed using a professional group of employees to either replace or outweigh
the CU corps. I seriously doubt many projects are going to be happy with vastly increasing
the amount of blocks implemented by the foundation on the basis of evidence that very few
can see.
Vermont has correctly summarised the issues that come with any auto-implementation of
IPBE.
But there clearly is a need to act on the growing set of problems, and DannyH's list
has many good options (and even the not so good options are the ones that obviously should
be considered to judge the tradeoff threshold).
If we can smooth the process for Stewards (on their side) to shrink the time needed for
each action, that's the same effect as having more active stewards. That let's us
consider options that currently may be a non-starter. We also need to smooth the process
for requesting unblocks (or even understanding the problem). No doubt this is excabated by
the "they can't hear you"
<https://en.wikipedia.org/wiki/Wikipedia:Mobile_communication_bugs> problems.
We absolutely need a process for simplifying and clarifying both understanding IPBE
(global/local) and then requesting it.
Now, I suspect most "innocent" proxies being added/blocked would probably become
"harmful" if unblocked (that is, sooner or later they'd be used
problematically), but that's definitely something that should be tested as we expand
on blocking proxies just because we know they're proxies.