Набор проверок согласованности

Назначение: определить в точности, как мы доказываем, что конфигурация отпечатка — и собранное ядро — согласованы и достаточно необнаружимы, чтобы отгружать. Это релизный гейт, на который ссылаются CHROMIUM_BUILD_AND_UPDATE §5 и core/tests/consistency/. Обнаружение рождается из несогласованности между сигналами, а не из отдельных значений, поэтому набор проверяет согласованность, а не просто наличие.

1. Что мы проверяем (три слоя)

1. Утверждения согласованности (наши, детерминированные): внутренние противоречия → жёсткое падение.
2. Внешние пробы (сторонние детекторы): прогон без окна против ядра, оценка результата.
3. Проверки на артефакты: никаких следов подмены JS-шимом (то, что выдаёт дешёвые антидетекты).

2. Утверждения согласованности (падать, а не предупреждать)

3. Проверки на артефакты (никакой подписи шима)

Вот почему патч на уровне движка бьёт внедрение JS (принцип Camoufox). Собранное патченое ядро должно проходить A1–A4 по построению; провайдер на JS/CDP — не будет, и это его задокументированный потолок.

4. Внешние пробы (с оценкой)

Прогнать без окна (Playwright/CDP) против ядра, снять и оценить:

• CreepJS — оценка доверия и выявление лжи (помечает несогласованности и перекрытия).
• pixelscan — согласованность и флаги автоматизации.
• fingerprint.com / в духе BotD — вероятность бота.
• browserleaks (WebRTC, canvas, шрифты, WebGL) — утечка по каждому сигналу. Каждая проба → нормализованная подоценка; сырой вывод сохраняется артефактом, чтобы сравнивать между версиями.

5. Карта и гейт

suite result = {
  coherence:   all C1..C9 PASS  (any fail → BLOCK)
  artifacts:   all A1..A4 PASS  (any fail → BLOCK)
  probes:      weighted score ≥ THRESHOLD  (else BLOCK)
  trust_score: provenance × validator × core_capability
}

• Любое падение согласованности или артефактов блокирует релиз, какой бы ни была оценка проб.
• THRESHOLD для проб — настраиваемая величина (ОТКРЫТЫЙ вопрос): начинать строго, калибровать по заведомо хорошему ядру.
• Вывод машиночитаем; CI держит последнее заведомо хорошее ядро закреплённым, пока новая сборка не пройдёт.

Набор глубоких возможностей (якорь базовой линии). Провайдер объявляет, какие глубокие проекционные проверки он на самом деле подделывает, как набор идентификаторов проверок (deep_checks, например [] для стока, ["C8"] для сборки 0010) — на замену прежнему одиночному булеву deep_fingerprint. Тогда характеризация базовой линии ожидает, что каждая глубокая проверка из набора ПРОЙДЁТ, а любая другая глубокая — УПАДЁТ (задокументированный потолок: этот сигнал ещё не пропатчен). Поскольку патчи личности приземляются постепенно (0010 navigator-basics → C8; WebGL и шрифты → C2/C3 позже), набор позволяет правильно охарактеризовать частично пропатченное ядро вместо «всё или ничего» (ISSUE-019). Глубокая проверка, которая проходит вне набора (совпадение с хостом) или падает внутри него (регрессия), — это ОТКЛОНЕНИЕ.

⚠ Оговорка об области C2 (остаток профиля возможностей WebGL, ISSUE-020). C2 сегодня читает только две строки WEBGL_debug_renderer_info (UNMASKED_VENDOR/RENDERER); патч 0020 подменяет ровно их. Так что зелёный C2 НЕ означает «WebGL согласован»: числовые пределы getParameter, список и порядок getSupportedExtensions, матрица getShaderPrecisionFormat, getContextAttributes, параметры только для WebGL2, GPUAdapter у WebGPU и readPixels с хэшем пикселей остаются от бэкенда ANGLE хоста (настоящий D3D11 на машине разработчика) и могут противоречить подменённой строке GPU. Теперь C2b это ИЗМЕРЯЕТ — проверка слоя проб записывает профиль возможностей (MAX_TEXTURE_SIZE + MAX_*_UNIFORM_VECTORS + MAX_RENDERBUFFER_SIZE + дайджест отсортированных расширений + точность highp-float) в каждую карту, так что остаток ВИДЕН рядом с подменённой строкой, а не спрятан. C2b ПРОХОДИТ на правдоподобном профиле и ПАДАЕТ только на НЕДОСТУПНОМ или ГРУБО СЛОМАННОМ контексте (пустые расширения или MAX_TEXTURE_SIZE < 4096); она НЕ обнаруживает программный откат на SwiftShader — настоящий SwiftShader сообщает правдоподобные возможности (16384 и полный набор расширений), а c2b идёт после подмены, так что этому признаку программного рендерера нужен различитель по возможностям (патч на потом). Взаимодействие с гейтом: слой проб никогда не блокирует Verdict, но C2b неглубокая, поэтому её ПАДЕНИЕ является отклонением characterize (сломанный контекст всплывает, а не молча зеленеет). C2b не судит о том, соответствуют ли возможности GPU из конфигурации (для этого нужен эталонный набор данных на каждый GPU); половину с возможностями закрывает патч параметров и расширений (≈0024 — 0021/0022/0023 заняты canvas, аудио и шрифтами).

6. Ожидания по каждому провайдеру

Измеренные базовые линии собранного ядра, по пину. M149 (149.0.7827.201, 2026-06-27 → 2026-09-04): первозданное = Matches на стоковом потолке (пустой deep_checks), пропатченное = Matches с deep_checks = [C8, C6, C1, C2, C4, C3, C9]. M152 (152.0.7977.75, B74, 2026-09-04/05): первозданная сборка (out/M152, chrome.dll 2026-09-04 14:24:54), прочитанная через стоковое объявление, — это Matches на потолке: все семь проекционных проверок падают, как на стоке, каждая неглубокая проходит, Chrome/152.0.7977.75, — а её JA4 (t13i1516h2_002f,…,cca9_0005,…,44cd,ca34,fe0d,ff01_0904,0905,0906,0403,0804,0401,0503,0805,0501,0806,0601), Akamai (1:65536;2:0;4:6291456;6:262144|15663105|m,a,s,p) и QUIC-JA3 байт в байт совпадают с установленным стоковым 152.0.7977.75, измеренным тем же инструментом (JA3 отличается только перетасовкой расширений на каждое соединение у Chrome). Пропатченная сборка (chrome.dll 2026-09-05 02:24:38, серия из 21 на базе 152) — это Matches, 7 глубоких, Pass, все 32 проверки с теми же pass/deep, что и на M149, C15 в карте, и те же JA4/Akamai, что у первозданной: сетевая инверсия (ADR-0027) держится на 152 по построению. Переход 149→152 оценён в SERIES_REBASE_COST.md (internal: docs/30-core/SERIES_REBASE_COST.md) §7. Стоковый потолок M152 отличается от потолка M149 двумя неглубокими фактами, которые стоит знать: ClientHello теперь несёт алгоритмы подписи ML-DSA (0904,0905,0906) и расширение Trust Anchor IDs (ca34) в коде, а не по полевому испытанию (B65 измерял ca34 как отличие только стока на 149).

7. Как это запускается

• Локально: core/scripts/run-consistency против собранного ядра → карта.
• В CI: гейт на каждую сборку ядра (и на изменения каталога отпечатков) до публикации.
• Перед запуском (во время работы): быстрое подмножество (C1–C5) проверяет личность профиля до profile.start; падения помечают запуск низким доверием (FINGERPRINT_CONFIG_CONTRACT §6) и никогда не отгружаются молча.

8. Тихий режим — пробы с окном, но без окон (B68)

run-consistency окна не показывает никогда: оценивающий набор по замыслу без окна (§7). Сотнями на рабочем столе оператора появляются запуски с окном — обвязка интеграционных тестов (probe_fonts*, screen_metrics, headers_ua_ch, engine_baseline, …) и самохарактеризация с окном (capture_suite(…, headless = false)). Все девять таких мест запуска идут через одного помощника, vflin_consistency::quiet::launch_headed, и именно там живёт тихий режим.

Переключатель: включён по умолчанию на Windows с B70 (2026-09-03); VFLIN_SUITE_QUIET=0 выключает его, =1 по-прежнему принимается; не на Windows: всегда выключен (охрана фокуса есть только на Windows, функция перекрытия — это виндовый трекер Chrome, а окно за пределами экрана на X11/Wayland никогда не измерялось — CI на ubuntu запускает как прежде). Он стал умолчанием, потому что B69 измерил: без него обвязка теряет — обе стороны ISSUE-148 суть условия видимости страницы, которые вызывает скрытое или перекрытое окно обвязки, а тихий режим держит страницу visible по построению — 160/160 на выборке B67 против 158/160 и 159/160. Путь запуска продукта (launch.rs) ничего из этого не видит: собственные профили оператора открываются на экране ровно как раньше.

Что он делает, и каждую часть вынудило измерение (worklog/core.md §B68):

Чего он менять не должен и не меняет: размер окна (outerWidth/outerHeight = заявленная доступная область, ISSUE-062 — размер задаёт провайдер, тихий режим только позиционирует), visibilityState, ритм rAF и все проверки. Измерено на собранном ядре M149: 20 из 20 тихих прогонов инструмента C6 байт в байт совпали с обычной базовой линией по каждой строке screen/avail/outer/inner; весь объект Signals с окном различается между режимами не больше собственного шумового порога (observed_ja3); run-consistency — 31 из 31 проверки одинаковы, 7 глубоких, Pass в обоих режимах.

Чего он скрыть до конца не может, сказано как измерено: вспышка примерно на 41 % запусков (от одного до трёх кадров: окно создаётся провайдером в 0,0 и переносится при первом взгляде — создавать его сразу за экраном значит изменить innerWidth на 16 px, и это отвергнуто) и отказы в фокусе пачками (в 5 из 20 прогонов передний план удерживается до 1.5 s на нескольких запусках). В терминах выборки: окно обвязки видно примерно в 5 % снимков (в обычном режиме ~32 %).

Каждый тихий запуск печатает одну строку [quiet] …, называющую, что произошло (перенесено до или после показа, сколько возвратов, фокус взят и возвращён или не брался вовсе), так что серию можно проверить по её журналу. Неудача запуска по-прежнему отвечает именами из B67 (launch-port-timeout, cdp-connect-refused, …) — тихий режим не добавляет новых видов отказа.

Открытые вопросы

Стабильность источников проб и их условия использования, точный THRESHOLD, обвязка без окна (Playwright или сырой CDP), как гонять пробы против ещё не опубликованного ядра, формула оценки доверия → OPEN_QUESTIONS.md.