extension: Flash version reported by the plugin polyfill (32.0) is below version gates used by post-EOL Chinese Flash sites (>=33), so Ruffle is never invoked on them

Is your feature request related to a problem?

Yes. The plugin polyfill reports the fake Shockwave Flash plugin with the description Shockwave Flash 32.0 r0, hardcoded in web/packages/core/src/plugin-polyfill.ts. While 32.0 is the final release of the international Adobe Flash Player, it is not the highest Flash version that exists in the wild. After Adobe's EOL, the Adobe-licensed distributor for mainland China (flash.cn, operated by Chongqing Zhongcheng Network) continued the version line independently: official release notes exist for 33.x, and the currently shipped builds are 34.0.0.380. Real-world sites in China are aware of this, and some deliberately gate their Flash detection on >= 33 so that only the maintained domestic player is accepted while zombie international installs (≤ 32) are rejected.

A verified real-world example is CNTV (China Central Television) politics archive pages, e.g. https://politics.cntv.cn/special/gwyvideo/likeqiang/201907/2019072301/index.shtml. Their player loader (js.player.cntv.cn/creator/common_standard.js) parses the version integer out of the plugin description and gates the desktop Flash path on it:

function getFlashVer() {
    var fls = flashChecker(); // parses navigator.plugins["Shockwave Flash"].description
    if (fls.f && fls.v >= 33) { isFlashPlayer = true; } else { isFlashPlayer = false; }
}

function writePlayer(fo, divId) {
    ...
    getFlashVer();
    if (!isFlashPlayer || ...) {
        showInstallFlashPlayerMsg(...);
        return; // ← no SWF element is ever created, so Ruffle is never involved
    }
    ...
}

With the extension installed, fls.v evaluates to 32 and the >=33 gate fails. The page shows an "install Flash Player" placeholder and the <object>/<embed> element that Ruffle's polyfill could replace is never created. These archive pages are permanent government content that will not be migrated to a modern player, so they will stay in this state indefinitely.

I verified end-to-end that the reported version is the only blocker: intercepting common_standard.js in flight and changing the gate from >=33 to >=32 (nothing else) makes the page create the SWF element, and Ruffle attaches to it immediately.

Describe the solution you'd like

Any of the following, in decreasing order of preference:

1. Make the reported version configurable (a global setting, optionally with a per-site override), defaulting to the current 32.0 r0. This preserves the existing fingerprint posture discussed in #8274 while letting users opt into a higher version for sites that gate on post-EOL domestic releases.
2. Alternatively, bump the default description to the currently maintained domestic release (Shockwave Flash 34.0 r0). In 2026 the only Flash Player builds still shipping anywhere are the 34.x domestic ones, so reporting 34.0 arguably resembles "the real Flash Player as currently deployed" more closely than 32.0 does. I understand this trades against the uniform-fingerprint argument in #8274, which is why option 1 is my primary suggestion.

Describe alternatives you've considered

Patching the page's detection script from another extension (webRequest.filterResponseData string replacement). It works — it is how I verified the analysis — but it is fragile, site-specific, per-site maintenance-heavy, and exactly the kind of thing Ruffle's plugin polyfill exists to avoid needing. Serving the streams through their direct URLs instead of the embedded player is orthogonal and does not restore the embedded experience.

Additional context

• The spoof currently uses a constant filename: "ruffle.js". Per #8274, the maintainers preferred constant values for privacy; a user-side version bump does not add a new fingerprint surface beyond what the constant description already exposes, which is why option 1 (opt-in configuration, default unchanged) is my primary suggestion.
• Related history: #448 and #501 (detection compatibility — the reason the polyfill exists), #24029 and PR #24062 (opt-out interaction), PR #16623 (scripting-based spoofing on Firefox), #5368 (the real Chinese Flash plugin crashing Ruffle — note this feature request does not execute any Chinese Flash code; it only changes a version string reported to detection scripts).
• The domestic Flash version claims are verifiable on flash.cn (release notes for 33.x; the debug-downloads page listing 34.0.0.380).
• Happy to provide additional data (HAR captures, more affected sites, or a minimal test page) if useful.