Unfortunately some legitimate services got caught up in our recent attempts to mitigate (yet another) bot-net attack on ListenBrainz.
You may find that a service you use is now being blocked, including Navidrome. We have also had reports of multi-scrobbler submissions being blocked, and there may be other affected services that haven’t yet been reported to us.
These services got caught up in recent blocks because they are/were not setting a proper user agent when calling the LB API.
Navidrome and multi-scrobbler are already pushing fixes!
If you are experiencing issues on another service, we would like to let you through, but without a user agent (UA) string we can’t identify the service’s traffic. Please ask your service to add a meaningful UA string (in a format like described in https://musicbrainz.org/doc/MusicBrainz_API/Rate_Limiting) so we can get you back up and running.
Implementing a good back off when they receive a 429 error will help avoid blocks too. For example, extending the waiting time between resubmissions, if the service repeatedly returns a 429. Note that some of the blocked services had this implemented already, but it can help.
Developers, you are always welcome to talk to us on the dev channel in ChatBrainz (Matrix/IRC/Discord) if you have any questions.
What does anyone gain from DDoSing such an innocuous service?
As I understand it is mostly AI web scraping bots causing huge amounts of traffic. Not an intentional DDoS, but still bad actors. They are intentionally trying to avoid blocks by accessing sites from a huge amount of IPs and ignore rate limits or robots.txt.
I’m using listenbrainz-mpd, and I don’t know if I would call what I’m experiencing rate-limiting. The scrobbler doesn’t send UA, yes, but I’m not just being rate-limited from the API, my whole network gets blocked for several minutes from accessing any of the *brainz services that live on `142.132.241.153`. A singular now-playing query is triggering the block, too, not even scrobbles.
“`
$ curl -v4 https://listenbrainz.org
* Host listenbrainz.org:443 was resolved.
* IPv6: (none)
* IPv4: 142.132.241.153
* Trying 142.132.241.153:443…
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
“`
That looks like an IP block. It’s what happened to navidrome instances yesterday. The problem is that the bots responsible for the huge traffic are using generic user agents and hammer the server from a huge amount of different IPs. That’s why generic user agents can receive a block like this.
The scrobbler should send a custom UA to avoid the issue, as described in the blog post.
This should be prominently added to the LB API docs. I was aware of the user agent policy for MB, but nowhere does it say that the same thing applies for LB.
Yes, that one is on us.
We’ve rectified this and added our user-agent requirements to the API docs: https://listenbrainz.readthedocs.io/en/latest/users/api/index.html#id5