Catching Octo Browser: FontCache Asymmetries and Client Hints Protocol Violations
How Octo Browser's C++ patches leave detectable FontCache metric splits on Windows and violate User-Agent Client Hints contracts on macOS and Linux.
- ✔ Octo forces status-bar to Segoe UI 12px but leaves caption as Arial 16px on Windows.
- ✔ Genuine Windows never returns Arial for caption font metrics.
- ✔ Returns invalid macOS marketing versions (14.x) instead of Darwin kernel versions (20+).
- ✔ Violates upstream Chromium Linux contract by populating empty-string platformVersion.
Catching Octo Browser: FontCache Asymmetries and Client Hints Protocol Violations
Octo Browser has built a strong reputation as one of the more technically sophisticated anti-detect browsers. Unlike older tools that rely purely on JavaScript wrappers, Octo patches Chromium directly in C++ to alter browser fingerprints before the JavaScript execution context ever initializes.
Despite this extra effort, Octo leaves behind subtle architectural bugs. When you modify a massive codebase like Chromium (tens of millions of lines of C++ code), it is very difficult to change one subsystem without breaking internal contracts with another.
In this article, we will examine two specific C++ engine flaws that uniquely identify Octo Browser:
- The Windows system font metric split in Blink's
FontCache - Protocol contract violations in Chromium's User-Agent Client Hints subsystem
[!NOTE]
Empirical Research Methodology & Test Scope
We evaluated 4 commercial anti-detect browsers (Dolphin{anty}, AdsPower, Octo Browser, and Multilogin), deploying these 4 browser test suites across 3 host operating systems (Windows, macOS, and Linux) against all 3 guest OS profiles (Windows, macOS, and Linux). Each environment was evaluated in both headed and headless modes—resulting in 72 comprehensive test matrix evaluations (18 distinct environment configurations per browser: 3 hosts × 3 profiles × 2 display modes) over 2 weeks of dedicated research to discover and validate these findings.
# 1. The Windows System Font Metric Split
In CSS, there are legacy system font keywords designed to match the host operating system UI:
- ◆
font: status-bar - ◆
font: caption - ◆
font: menu - ◆
font: small-caption - ◆
font: message-box
In upstream Chromium, Blink's layout engine delegates these font keywords to FontCache.
- ◆On genuine Windows: Windows uses the
Segoe UIfont family for bothstatus-barandcaption. Crucially,captionon Windows is neverArial. - ◆On genuine macOS and Linux: Neither OS uses Segoe UI natively. Chrome maps both
status-barandcaptionto the default sans-serif fallback, which resolves toArial 16px.
The Octo C++ Patch Flaw
When you create a Windows profile in Octo Browser, Octo applies a custom C++ patch named csswindowssystem_font.
Octo's developers wanted to ensure that CSS queries for Windows system fonts returned Segoe UI. In their patch, they implemented hooks for:
- ◆
SetStatusFontMetrics - ◆
SetMenuFontMetrics - ◆
SetSmallCaptionFontMetrics
These functions force status-bar, menu, and small-caption to resolve to Segoe UI at 12px.
However, Octo forgot to patch caption, icon, and message-box. Those functions remain untouched and fall back to Arial at 16px.
The Anomaly
If you measure the computed styles of temporary DOM elements styled with these keywords on Windows:
const el = document.createElement('div');
el.style.font = 'status-bar';
const sbStyle = window.getComputedStyle(el);
// sbStyle.fontFamily -> "Segoe UI", sbStyle.fontSize -> "12px"
el.style.font = 'caption';
const capStyle = window.getComputedStyle(el);
// capStyle.fontFamily -> "Arial", capStyle.fontSize -> "16px"In Octo Browser on a Windows profile:
- ◆
status-barisSegoe UI 12px - ◆
captionisArial 16px
This combination is impossible in authentic Google Chrome. On a real Windows machine, both are Segoe UI. On Mac or Linux, both are Arial. Finding Segoe UI on status-bar while caption remains Arial is a signature unique to Octo's incomplete font patch.
# 2. Client Hints Architectural Contract Violations
User-Agent Client Hints (navigator.userAgentData) is modern Chromium's replacement for the legacy User-Agent string.
Websites request high-entropy platform details asynchronously using:
navigator.userAgentData.getHighEntropyValues([
'platform',
'platformVersion',
'fullVersionList'
]);Upstream Chromium derives these values through strict platform-specific C++ logic in:
components/embeddersupport/useragent_utils.cc
Octo attempts to spoof these fields, but violates Chromium's internal specifications in two major ways.
A. The macOS Darwin Kernel Contract
In genuine Chromium on macOS, platformVersion is not the marketing version of the OS (like macOS 14 Sonoma or macOS 15 Sequoia).
Instead, Chromium derives platformVersion directly from the Darwin kernel version using base::SysInfo::OperatingSystemVersionNumbers.
- ◆macOS 11 Big Sur uses Darwin 20
- ◆macOS 12 Monterey uses Darwin 21
- ◆macOS 13 Ventura uses Darwin 22
- ◆macOS 14 Sonoma uses Darwin 23
Because Chromium dropped support for macOS 10.15 (Darwin 19) in Chrome M116, every modern version of Google Chrome running on macOS returns a platformVersion major number of 20 or higher.
Octo's profile generator makes an amateur mistake: when a user creates a macOS 14 profile, Octo sets platformVersion to "14.0.0".
Any modern Chromium build claiming to run on macOS that returns a platformVersion below 20 is an immediate, mathematically proven anti-detect spoof.
B. The Linux Empty String Contract
On Linux, Chromium's upstream code in useragentutils.cc explicitly sets platformVersion to an empty string (""):
// Upstream Chromium user_agent_utils.cc snippet:
#if BUILDFLAG(IS_LINUX)
return "";
#endifGoogle designed Client Hints this way on Linux to prevent fragmentation and user tracking across thousands of Linux distributions and kernel revisions.
Octo's profile configurator often populates platformVersion on Linux with kernel version strings (like "5.15.0" or "6.2.0"). A non-empty platformVersion on Linux breaks the Chromium specification.
# The Octo Detector Code
Combining the font asymmetry check with Client Hints contract validation gives us an accurate detector:
window.detect_octo = async function () {
try {
// 1. Windows FontCache asymmetry check
if (typeof document !== 'undefined' && document.createElement && typeof window.getComputedStyle === 'function') {
const isWin = typeof navigator !== 'undefined' && (
navigator.platform === 'Win32' ||
navigator.userAgentData?.platform === 'Windows'
);
if (isWin) {
const root = document.body || document.documentElement;
if (root) {
const el = document.createElement('div');
el.style.display = 'none';
root.appendChild(el);
try {
el.style.font = 'status-bar';
const sbStyle = window.getComputedStyle(el);
const sbFamily = sbStyle.fontFamily || '';
const sbSize = sbStyle.fontSize || '';
el.style.font = 'caption';
const capStyle = window.getComputedStyle(el);
const capFamily = capStyle.fontFamily || '';
const capSize = capStyle.fontSize || '';
const isOctoFontAsymmetry = sbFamily.includes('Segoe UI') &&
!capFamily.includes('Segoe UI') &&
capFamily.includes('Arial') &&
sbSize === '12px' &&
capSize === '16px';
if (isOctoFontAsymmetry) {
return true;
}
} finally {
el.remove();
}
}
}
}
// 2. Client Hints contract verification
if (navigator.userAgentData && typeof navigator.userAgentData.getHighEntropyValues === 'function') {
const hints = await Promise.race([
navigator.userAgentData.getHighEntropyValues(['platform', 'platformVersion', 'fullVersionList']),
new Promise(resolve => setTimeout(() => resolve(null), 1000))
]);
if (hints) {
const platform = hints.platform || navigator.userAgentData.platform;
const platformVersion = hints.platformVersion;
// macOS: Must be Darwin kernel version (>= 20)
if (platform === 'macOS' && typeof platformVersion === 'string') {
const major = parseInt(platformVersion.split('.')[0], 10);
if (Number.isFinite(major) && major < 20) {
return true;
}
}
// Linux: Chromium contract specifies platformVersion must be an empty string
if (platform === 'Linux' && typeof platformVersion === 'string' && platformVersion.length > 0) {
return true;
}
}
}
return false;
} catch {
return false;
}
};# Takeaways
Even when an anti-detect browser compiles custom C++ patches, modifying Chromium correctly is an enormous engineering challenge.
When vendors rush features to market without full integration testing against upstream Chromium specifications, they create signature flaws that advanced bot management platforms like Verisoul, DataDome, and Cloudflare turn into instant detection rules.
If your web scrapers or multi-accounting operations require true undetectability, you cannot rely on off-the-shelf browsers whose patches are already indexed and mapped. You need custom browser automation built directly on the exact C++ contracts Google Chrome enforces.
