@ansuz @oblomov Looking at my logs, most RSS readers are unaffected: they either use their own user agent, and don't try to pretend to be Firefox or Chrome, or they are running within a real browser, in which case the expected headers will be there.
Quick look at my logs from yesterday:
2582 total requests against atom.xml on my blog.
105 unique user agents
Only 24 of those user agents had Chrome/ or Firefox/ in their user agent
These 24 made 165 requests total.
Out of that 165, 54 did not have sec-fetch-mode.
Out of those 54, the majority came from either Cloudflare or Amazon, or another cloud provider.
Still out of those 54, 21 pretended to be Firefox, but the user agent wasn't what a real browser sends: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 - in real browsers, rv and the Firefox/ version match. (All 21 were from Cloudflare IPs too)
Still out of the 54, 27 pretended to be Chrome, but did not send a sec-ch-ua header, nor sec-fetch-mode, and they said they're Chrome/84.0.4147.105 from 2020 - coming from Amazon AWS. I don't believe for a second these would be real browsers.
This leaves us with 6 requests that may have come from legit browsers. Five of those were Chrome on Android, coming from a DigitalOcean IP, without sec-fetch-mode or sec-ch-ua. I don't think those were legit.
There was one Firefox/, coming from an American residential IP, without sec-fetch-mode... that might have been legit, maybe?
But out of 2.5k requests, 1 false positive1 is, imo, acceptable.
Of course, what's acceptable varies a lot, and the people who visit (or rather, subscribe to) my blog are likely a bit atypical.
What I'm trying to convey here is that the majority of RSS readers don't pretend to be Firefox or Chrome, or - because they're running in one - send the appropriate headers anyway.
It is likely a false positive, that IP made a single request the entire day.ย โฉ๏ธ