[bugs.kde.org] [Bug 523833] New: bugs/invent: User-Agent rules return a silent 403; `PPC` matches ppc64le and blocks current Firefox

https://bugs.kde.org/show_bug.cgi?id=523833

            Bug ID: 523833
           Summary: bugs/invent: User-Agent rules return a silent 403;
                    `PPC` matches ppc64le and blocks current Firefox
    Classification: Websites
           Product: bugs.kde.org
      Version First unspecified
       Reported In:
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: ---

Scraper traffic is a real and expensive problem, and I am not asking for the
anti-bot rules to be dropped. This report is about side effects of the current
User-Agent rules that look unintended — one of them is a plain regex bug — and
the fixes below are cheap and do not weaken the filter.

`bugs.kde.org` and `invent.kde.org` refuse a range of ordinary desktop browser
signatures with a 403, including some that no user can do anything about. The
two hosts do not carry the same rules, which is itself one of the findings
below. The response depends on the `User-Agent` header alone: repeating probes
with and without cookies, from different source addresses and over both IPv4
and
IPv6 changed nothing. Everything below is measured with `curl`, every probe
repeated.

## 1. The refusal is silent, and it hides itself

On `bugs.kde.org` a blocked visitor gets Apache's stock 403 with no explanatory
text (that is the body I saw; I did not inspect Invent's). There is no way
to tell a server outage from a rule that dislikes your browser, and nothing
points at the `User-Agent` header. The failure mode is self-concealing: someone
cut off from `bugs.kde.org` is by definition unable to file a bug about being
cut off from `bugs.kde.org`. Consistent with that, there is nothing in
Bugzilla:
I went through all 128 bugs filed against the `bugs.kde.org` product since 2024
and searched for `forbidden`, `useragent` and `403` — nobody has reported this
through the tracker.

People do hit *something* and cannot work out what, and the reports were
reasonably attributed to their own systems, because from the inside they are
not
reproducible: KDE contributors are overwhelmingly on Linux, where the rules
almost never fire. I want to be precise about what these threads do and do not
prove. They show unexplained 403s that nobody could diagnose. They are not
confirmed instances of these rules — the causal evidence is the measurements in
section 4, not these threads.

- discuss.kde.org thread 45283 (posts 19-20, 2026-03-18, two weeks after
  the rules landed) — 403 on Invent and on app pages; answered with "this is
  probably on your end, I cannot reproduce it".
- discuss.kde.org thread 47925 (2026-06-19) — links from kdenlive.org to
  Invent return 403; two people reproduce, two do not, thread ends unresolved.
- discuss.kde.org thread 11 (post 8, 2026-07-04) — same symptom, no reply.

**Suggested fix:** an `ErrorDocument 403` pointing at one small static page
that
says the request was refused by a User-Agent filter, and gives an address that
is
reachable without passing that filter. It tells an automated client nothing it
could not establish by trying a handful of strings, and it gives a person the
only means they have of understanding what happened.

## 2. `PPC` is matched as a substring and blocks current Firefox on POWER

This one is not a policy question, it is a regex bug, and it is what made me
write in:

    Mozilla/5.0 (X11; Linux ppc64le; rv:153.0) Gecko/20100101 Firefox/153.0
    → 403 from bugs.kde.org

That is the newest Firefox on the newest Linux, refused solely because the
platform token contains `ppc64le`, and the rule tests for the substring `PPC`
case-insensitively with no boundaries:

    RewriteCond %{HTTP_USER_AGENT} (Presto|Trident|PPC) [NC,OR]

The identical string with `x86_64` in place of `ppc64le` returns 200, so
nothing
else about it is at fault. The same `ppc64le` string passes on
`invent.kde.org`,
so this is about what the Apache snippet does on `bugs.kde.org`, not about
Bugzilla itself.

The rule was presumably aimed at ancient spoofed PowerPC Mac signatures, but it
also lands on live 2026 hardware — Raptor/Talos POWER workstations, which is
about as close to a core KDE audience as it gets.

**Suggested fix:** a word boundary, or matching `PPC Mac OS X` instead of bare
`PPC`. No automated client gains anything, and nothing else changes.

## 3. The Linux and Windows/macOS thresholds are 45 releases apart

Same browser, same version, different `Windows NT`/`Macintosh`/`X11` token:

- Chrome 100, released in 2022, from Linux → 200
- Chrome 145, six releases behind current stable, from Windows → 403

If the goal is "block outdated browsers", those two are hard to reconcile. On
Linux the cutoff falls somewhere between Chrome 90 (refused) and Chrome 100
(accepted) — the ancient two-digit rule; on Windows/macOS it is 45 releases
higher. Whatever number is chosen, applying the same age policy on every
platform would make the behaviour explainable to users without letting through
any additional stale-UA clients.

The full measurement table, the exact User-Agent strings, and the remaining
sections (where the rules come from, two configuration discrepancies, who is
affected, suggested fixes) follow in a comment — the first attempt to file this
with them inline was rejected by the spam filter.

-- 
You are receiving this mail because:
You are watching all bug changes.