This is worth discussing with our Traffic team. @BBlack, @ema: what is your point of view on rate-limiting browser without referer?

Varnish is probably where it would make sense to implement such limit as we do expect most requests to be cached at the Varnish level. As far as I know, this is not something we currently do on Varnish and probably not something we want to do as it requires additional state on Varnish.

We do *some* rate limiting on WDQS at nginx level, more to prevent unchecked abuse than to have a hard rate limit. But WDQS queries are not expected to be cached. We do not have a component able to do rate limiting in the maps flow as far as I know.

@Gehel will chat with the Traffic team about this.

After some discussion with @ema and @BBlack:

TL;DR - there's lots of fancy thoughts to have about the long term, but pragmatically there's not much we can do at all except what we're doing in all the other apps' cases: set fairly high per-IP ratelimits, *maybe* set them lower for empty/super-short UA strings as a warning, and anything more complicated is a year+ away when something or other is better-resourced and we can make loftier plans.

We probably want to do some analysis of what is a reasonable per-IP ratelimit for maps (@mpopov might be able to help), but we don't want to do anything more fancy at that time. See the IRC logs for the details of the conversation (15:50 to 16:42).

This can be closed, doing analysis of per-IP rate limit is done on T169175.