Re: New global API rate limits deployed for anonymous requests

Okay yes, that definitely makes sense.

I think these policies are definitely necessary given current traffic
patterns of abuse. I am very concerned about "legacy" tools however. If
you've spent time on the cloud mailing list, it seems like there are
multiple emails each year about "unclaimed" and "abandoned" projects and
the like. General issues of code rot and maintenance aside, as Piotr
mentioned there are many tools like this that are actively and extensively
used despite not being updated for a decade. This policy might end up being
a "hard deprecation" of such tools unless there is further deliberate
consideration.

(This may be a good focus for a hackathon, but I digress.)

I understand that "Referer" is a clear abuse vector, and is intolerable
from an "airtight" security posture, but maybe the benefits in terms of not
disrupting community workflows could outweigh the risks? Perhaps we could
monitor the traffic using this "workaround" and be prepared to cut off the
exception at any time once it is discovered by bad actors? Obviously this
wouldn't work if an additional unstated goal of this effort is to actually
reduce overall usage/costs.

Thanks,
-Travis

On Mon, Mar 16, 2026 at 6:54 AM Daniel Kinzler <[email protected]>
wrote:

> Am 16.03.26 um 12:07 schrieb Travis Briggs via Wikitech-l:
>
> Great idea, I think Referer is completely reasonable as a rate limiting
> signal, because it is no worse than User-Agent from a spoofing/abuse
> perspective.
>
>
> Because the User-Agent is spoofable, we will likely stop using it as a
> rate limit key soon-ish for requests coming from outside WMCS. Sending a
> compliant user-Agent will give you a better rate limit than not doing so,
> but not a *great* limit. So adding more untrusted headers into the mix is
> not going to help
>
> In the long run, authenticating, or asking users to authenticate, will be
> the only way for apps and bots to ensure virtually unlimited API access.
> Unauthenticated traffic will generally be rate limited per IP.
>
> --
> Daniel Kinzler
> Principal Software Engineer
> MediaWiki Engineering Group
> Wikimedia Foundation
>
>
>

_______________________________________________
Wikitech-l mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/