What is the point of these bots endlessly trying utterly random HTTP requests?

I can't be the only one seeing this kind of garbage in my server logs:

"GET /!?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /HotelInformation/HotelInformation.aspx?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /++?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.cancel?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.specialSubmit?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /img.youtube.com?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.droppable/?asdas1230ds0a=da90sue21qh HTTP/1.1"
"POST /.droppable/ HTTP/1.1"
"GET /_isMasked/?iqi_localization_country=x27f&vst=x27f&gitlab=x27f&1111ef1ee11b=x27f&ocxlaarct7tk=x27f&gad_source=x27f&landcode=x27f&confirmPrivacyStatement=x27f&26=x27f&frm_action=x27f…"

This is just a tiny sampling of endless junk that has been going on for at least the past 2 weeks. The last example is abbreviated, it goes on like that, with exactly 100 of those random query parameters that always have the same value “x27f.” It are several bots, which according to an IP locator service come from different countries, mostly the UK and Hong Kong. However, doing a WHOIS on each of the IP addresses reveals that many of them are hosted by Contabo GmbH, a cheap VPS hosting service in Germany.

Something similar has happened years ago, and then the junk also came from Contabo-hosted addresses. The pattern was similar, but each request then looked like the last example shown above, using a ridiculous number of query parameters with different field names but all the same value “z3re”. I filed an abuse report back then, and the junk stopped for a while, but it has been sporadically returning, and now it is back in a slightly different incarnation, but it still makes no sense at all. NONE.

Often these bots will still perform requests with a ridiculous number of parameters (usually 100), but more often they look like the above: a random string with the same damn query string appended to it. I really mean the same damn string for at least 2 weeks straight, which in the above case was obviously produced by someone bashing their keyboard: “asdas1230ds0a” and “da90sue21qh”. The same bot will keep on doing requests with the same base path like “.specialSubmit” or “London” for a whole day, and then might switch to another string for the next day, if I haven't kicked its ass with an iptables DROP in the meantime. The choice of these strings generally makes no sense. Lately they have also started using random characters next to city names and domains or just random words. Most of the time, the strings don't look like anything a real web app would ever use. It is all totally random. The mind boggles.

I really don't understand what is being tried to achieve with this. It is as if they are trying to brute force the internet in the hopes of finding an exploit, but the chances of this strategy producing anything fruitful is negligibly small, especially when not even varying the query parameters. Also, they do only 1 request about every 10 minutes, maybe to try to stay under the radar of suspicious activity detectors (not mine, obviously). At such slow rate, a Monte Carlo approach is just pointless.

I truly cannot grok what could be going in in the mind of whatever crackpot implemented this piece of junk and then decided to pump Kilowatts into a server farm to unleash this nonsense across the internet. If I see this in my logs, then it probably means they do these requests non-stop on whole IP ranges or a list of domains obtained from wherever. All that electricity is wasted on total nonsense. They had better spent the effort on mining crypto. It must take a very special kind of mental deficiency to believe this strategy will yield any return on investment.

Luckily the incomprehensible act of always using the same strings in the request, makes it easy to ban these bots. The set of IP addresses they work from is also pretty stable, so firing up the firewall is a good option as well.

The Music app in Mac OS 14 Sonoma causes pauses in the whole rest of the system

TL;DR: if you encounter hiccups in the UI while playing music, close the Music app window to avoid this. OR, open any program that uses 3D acceleration of any kind, it will also make the hiccups magically vanish. And please report this through Apple feedback.

My MacBook Pro “upgraded” itself to Mac OS Sonoma during a routine reboot, without my consent. This wouldn't be that bad if this new release of the OS would not be riddled with bugs. One apparent bug was that when the Music app starts playing the next track, and the display is sleeping, there would only be an empty notification temporarily waking the screen, with nothing else in it than the Music icon and the word “Music”. In previous releases this would show full song information as expected. Eventually I figured out that this is a ‘feature’: one needs to give the Music app explicit permission to show information on a “locked” screen, even though the screen is not actually locked in my case. Why it is then still allowed to show a pointless empty notification, beats me. Apple is starting to adopt Microsoft style logic.

Anyhow, on to the true bug that is the main topic of this post, and it is a bad one. It is quite simple:

• Playing local M4A or MP3 files will cause the whole system UI to freeze during about 1 second, approximately every 7 seconds. EXCEPT the Music app itself, which somehow remains immune against theze hiccups. Otherwise you will notice this by things momentarily hanging while scrolling, typing, or doing anything else that requires smooth updating of the screen (even video playback will stutter).
• Playing an internet radio stream will cause same UI freezes, but only when the metadata in the stream causes the status display in the Music app to change. For instance, if the stream contains artist and title information, you can expect everything to choke at the start of every new song. Somehow I have a knack for finding these weird correlations, I don't know why, but it only took about 4 occurrences to figure this out, then I confirmed it by doing some explicit tests.
• These nuisances only occur if the Music app window is open. Close it and the hiccups no longer occur. Of course I mean closing only the window, not quitting the whole app (which would obviously fix any problems caused by the app running).

I don't even know what could cause this. The days when playing an MP3 file required almost all CPU resources of a machine, are way behind us (I still remember one of my friends boasting about this with his 4/86). This seems like some kind of real-time priorities problem, or some UI rendering bug. The 14.3 update mentioned something about a performance problem with UI rendering, but alas, it definitely did not fix this bug because I still encounter it in Sonoma 14.3.1.
I bet it has something to do with all the unwanted security and privacy junk that is being poured into the OS, I wish there was just a big master toggle switch in the control panel “I am not an idiot, don't lock down my computer” to disable all this stuff.

How this kind of bug can have slipped through QA, is beyond me. I guess they don't really test playing local files anymore, assuming everyone will be happy to move to stupid streaming services that produce a steady revenue and that can be manipulated at leisure. However, I find reports in many places of Sonoma being sluggish and unresponsive, and I suspect that the Music app is not the only one causing this. It must be some deeper-level problem of which this is only one manifestation.

Update 2024/03/23: this is definitely some kind of rendering problem.

After some more experimenting, I found out that leaving certain other apps open, will also avoid the problem, even if the Music app window is visible while it is playing music. The magic apps that avoid the problem, are the ones that use OpenGL or some other kind of 3D acceleration. For instance Blender or OpenSCAD will do the trick, and even SheepShaver because it also relies on OpenGL as far as I can remember from when I was remotely involved in its development. Now I can only hope someone at Apple reads this and it gives them a clue about how to fix it…