Description
Self-hosted steel-browser-api (v0.5.3 / fingerprint-generator@2.1.82) fails to launch any browser when fingerprint injection is enabled. Every launch throws:
Fingerprint error during generation: Failed to generate a consistent fingerprint after 10 attempts
[CDPService] LAUNCH ERROR (FINGERPRINT)
Failed after 3 attempts
The only way to get a working browser is to set SKIP_FINGERPRINT_INJECTION=true, which disables the anti-detection layer entirely — defeating the purpose of fingerprint injection and making the browser trivially detectable (e.g. by Cloudflare managed challenges).
This appears related to #294 / #295.
Root cause
In api/src/services/cdp/cdp.service.ts, the desktop fingerprint options hardcode:
browsers: [{ name: "chrome", minVersion: 146 }],
screen: {
minWidth: this.launchConfig!.dimensions?.width ?? 1920,
minHeight: this.launchConfig!.dimensions?.height ?? 1080,
maxWidth: this.launchConfig!.dimensions?.width ?? 1920,
maxHeight: this.launchConfig!.dimensions?.height ?? 1080,
},
fingerprint-generator@2.1.82's bundled dataset has no Chrome 146 desktop-Linux samples at any resolution ≤ 1920×1080. Because the screen constraint is a fixed box (minWidth === maxWidth === 1920, minHeight === maxHeight === 1080), the generator finds zero matching records and exhausts all 10 retries.
Reproduction (run inside the api container):
const { FingerprintGenerator } = require("fingerprint-generator");
const opts = (screen) => ({
devices: ["desktop"], operatingSystems: ["linux"],
browsers: [{ name: "chrome", minVersion: 146 }],
locales: ["en-US", "en"], screen,
});
// FAIL — no Chrome 146 samples at fixed 1920x1080
new FingerprintGenerator(opts({ minWidth:1920, minHeight:1080, maxWidth:1920, maxHeight:1080 })).getFingerprint();
// FAIL — range still capped at 1920x1080
new FingerprintGenerator(opts({ minWidth:1280, minHeight:720, maxWidth:1920, maxHeight:1080 })).getFingerprint();
// OK — open-ended min lets it pick a larger Chrome 146 sample (e.g. 1600x1200)
new FingerprintGenerator(opts({ minWidth:1280, minHeight:720 })).getFingerprint();
// OK — older minVersion has samples at fixed 1920x1080
new FingerprintGenerator({ ...opts({ minWidth:1920,minHeight:1080,maxWidth:1920,maxHeight:1080 }), browsers:[{name:"chrome",minVersion:144}] }).getFingerprint();
So the failure is specifically the intersection of minVersion: 146 and a fixed screen box ≤ 1920×1080.
Impact
- Any self-hosted deployment on the current image cannot use fingerprint injection at all.
- Forces
SKIP_FINGERPRINT_INJECTION=true, which makes sessions detectable (navigator.webdriver exposed, no fingerprint spoofing). Sites behind Cloudflare managed challenges block these sessions.
Suggested fix
Make fingerprint generation resilient instead of fatal: attempt the strict (latest Chrome + requested screen) options first, and on failure retry with relaxed constraints (drop the upper screen bound / lower minVersion) before giving up. This keeps the newest fingerprints when the dataset supports them and degrades gracefully when it doesn't, instead of failing the entire browser launch. PR to follow.
Environment
- Image:
ghcr.io/steel-dev/steel-browser-api:latest (v0.5.3)
fingerprint-generator@2.1.82
- Self-hosted via docker-compose,
chrome default desktop sessions
Description
Self-hosted
steel-browser-api(v0.5.3 /fingerprint-generator@2.1.82) fails to launch any browser when fingerprint injection is enabled. Every launch throws:The only way to get a working browser is to set
SKIP_FINGERPRINT_INJECTION=true, which disables the anti-detection layer entirely — defeating the purpose of fingerprint injection and making the browser trivially detectable (e.g. by Cloudflare managed challenges).This appears related to #294 / #295.
Root cause
In
api/src/services/cdp/cdp.service.ts, the desktop fingerprint options hardcode:fingerprint-generator@2.1.82's bundled dataset has no Chrome 146 desktop-Linux samples at any resolution ≤ 1920×1080. Because the screen constraint is a fixed box (minWidth === maxWidth === 1920,minHeight === maxHeight === 1080), the generator finds zero matching records and exhausts all 10 retries.Reproduction (run inside the api container):
So the failure is specifically the intersection of
minVersion: 146and a fixed screen box ≤ 1920×1080.Impact
SKIP_FINGERPRINT_INJECTION=true, which makes sessions detectable (navigator.webdriver exposed, no fingerprint spoofing). Sites behind Cloudflare managed challenges block these sessions.Suggested fix
Make fingerprint generation resilient instead of fatal: attempt the strict (latest Chrome + requested screen) options first, and on failure retry with relaxed constraints (drop the upper screen bound / lower
minVersion) before giving up. This keeps the newest fingerprints when the dataset supports them and degrades gracefully when it doesn't, instead of failing the entire browser launch. PR to follow.Environment
ghcr.io/steel-dev/steel-browser-api:latest(v0.5.3)fingerprint-generator@2.1.82chromedefault desktop sessions