2026년 8월 25일, Chrome 152가 Windows, Mac, Linux, ChromeOS 및 Android의 안정적인 채널에 도착하여 navigator.cpuPerformance 속성을 가져왔습니다. 이는 사이트가 동기적으로 읽는 0에서 4 사이의 숫자로, 권한 없이 단일 계산 주기 없이 이루어집니다. 이는 비디오 통화와 스트리밍을 위한 힌트로 설계되었습니다: 약한 장치에는 배경 흐림 없이 240p를, 강력한 장치에는 효과가 있는 1080p를 제공합니다. 출시 후 2주가 지나면서 스크래핑 산업은 다른 문제를 논의하고 있습니다: 안티봇 시스템에 저렴하고 안정적인 하드웨어 신호가 생겼습니다.
브라우저가 제공하는 것
이 속성은 기가헤르츠나 프로세서 모델이 아니라 성능의 "티어"를 반환합니다. WICG의 설명서에 따르면 티어는 네 가지로 나뉩니다:
- 0 — 장치 분류 실패;
- 1 — 무거운 작업에 거의 적합하지 않음;
- 2 — 약하지만 작동 가능;
- 3 — 일반적인 시나리오에 적합;
- 4 — 성능이 뛰어나며 멀티태스킹에 여유가 있음.
사양은 공급업체, 모델 이름 및 코어 수를 공개하는 것을 명시적으로 금지하며, HTTPS를 요구하고 프라이버시 목표를 설정합니다: 각 티어는 인터넷에서 눈에 띄는 장치의 비율을 커버해야 하며, 수백 개의 다양한 CPU 모델을 포함해야 하므로 값이 청중을 단일 장치로 좁히지 않도록 해야 합니다.
Chromium에서의 실제 구현은 사양보다 간단했습니다. Zyte의 분석에 따르면, 분류는 주로 논리 코어 수와 내장된 상승 및 하락 표에 기반합니다: 주파수는 전혀 고려되지 않으며, 사양에서는 이를 허용합니다. 상승은 AMD Ryzen, Intel Gracemont 코어, Apple 실리콘 및 Intel Core Ultra가 받고, 하락은 Intel Atom 및 Core 2 시대의 프로세서가 받습니다. 대략적인 분류는 다음과 같습니다: 단일 코어 및 매우 약한 기계는 첫 번째 티어에 속하고, 두–네 개의 코어는 두 번째, 네–열 개의 코어 또는 현대의 에너지 효율적인 칩은 세 번째, 여덟 개 이상의 코어는 Core Ultra, Apple M 시리즈 및 열 개 이상의 코어는 네 번째에 해당합니다.
왜 이것이 감지 신호인지, 단순한 엔트로피 바이트가 아닌가
그 자체로 값은 약합니다: 다섯 가지 옵션은 약 2.3 비트의 엔트로피를 제공합니다. 이는 인터페이스 언어가 제공하는 것보다 적습니다. 위험은 세 가지 다른 속성에 있습니다.
무료입니다. JS의 실제 실행 속도를 타이밍으로 측정하려면 감지 스크립트가 프로세서를 수십 밀리초 동안 점유해야 하며, 이는 프로파일러에서 눈에 띕니다. 여기서는 속성을 동기적으로 읽는 것이며, 비용이 없고 흔적도 없습니다.
안정적입니다. 값은 검사 시점의 기계 부하에 의존하지 않습니다: 이는 하드웨어 클래스이지 현재 사용량이 아닙니다. 세션 간, 재시작 간 및 IP 변경 간에 동일하게 유지됩니다. 즉, 장기적인 프로필 식별자의 일부로 적합합니다.
일관성을 검사할 수 있습니다. 이것이 가장 중요합니다. 현대의 안티봇 엔진은 일반적으로 하나의 필드로 금지하지 않습니다 — 그들은 세트 내의 내부 모순을 찾습니다. 네 번째 티어를 주장하는 장치는 신뢰할 수 있는 navigator.hardwareConcurrency, 합리적인 navigator.deviceMemory, 현대의 GPU 렌더러 문자열 및 적절한 JS 실행 속도로 이를 확인해야 합니다. 네 번째 티어를 제공하면서 두 코어 가상 머신으로 벤치마크를 실행하는 프로필은 사소한 교차 검증으로 잡힙니다.
별도로, "데이터 센터 대 실제 사용자"의 경계가 거의 완성됩니다: 전형적인 클라우드 인스턴스는 두 개의 vCPU에서 첫 번째 티어를 정직하게 보고하며, 소비자 노트북과 전화는 세 번째–네 번째 티어에 해당합니다. 저렴한 VPS에서 헤드리스 모드로 실행되면서 일반적인 Windows의 Chrome으로 자신을 속이는 스크래퍼에게는 불편한 조합입니다.
이것이 항상 존재했던 hardwareConcurrency와 어떻게 다른가
합리적인 질문입니다: 사이트는 이전에도 navigator.hardwareConcurrency를 통해 코어 수를 읽었고, 메모리 용량은 navigator.deviceMemory를 통해 읽었습니다. 무엇이 변경되었습니까?
연결성이 변경되었습니다. hardwareConcurrency는 원시 숫자이며, 이는 오래전부터 대체되었습니다: 32 대신 8을 설정하면 문제가 해결됩니다. cpuPerformance는 브라우저가 내장된 표에 따라 계산한 파생 값입니다. 세트에 두 개의 필드가 존재할 때, 그 중 하나가 다른 하나에서 계산되면, 일방적인 수정은 그들 간의 연결을 끊습니다. 네 개의 코어를 설정했지만 티어가 여전히 네 번째인 경우, 구현 논리에 따라 이는 Apple 실리콘, Core Ultra 또는 열 개의 코어가 필요합니다. 따라서 코어 수가 거짓이거나 GPU 문자열이 거짓이며, 감지기는 단순히 불일치 사실을 감지하면 됩니다.
바로 이 때문에 오래된 체크리스트 "프로필에서 어떤 필드를 수정해야 하는가"는 한 항목이 아닌 전체 블록으로 구식이 됩니다: 이제 올바른 질문은 "어떤 일관된 하드웨어 구성의 조합이 있는가"입니다.
누가 가장 큰 영향을 받는가
Chromium 전용입니다 — 그리고 이는 완화 요소가 아닙니다. WebKit은 이 API에 대해 "반대" 입장을 취했으며, Mozilla는 공개적인 입장을 밝히지 않았으므로 Safari와 Firefox에서는 이 속성이 없을 가능성이 높습니다. 그러나 생산 자동화의 대부분은 Playwright, Puppeteer, nodriver, Patchright, 에이전트 브라우저와 같이 Chromium에 기반하고 있습니다. 즉, 신호는 가장 적게 예상되는 틈새로 날아옵니다.
가장 큰 모순은 모바일 프로필의 에뮬레이션에 타격을 줍니다. 안티 감지 프로필이 Android 스마트폰으로 자신을 속이고 cpuPerformance가 "4"라고 응답하는 경우, 브라우저가 물리적으로 Ryzen이 장착된 데스크톱에서 실행되고 있다면 이는 사소한 부정확성이 아니라 상호 배타적인 신호 쌍입니다. 동일하게 농장 시나리오에서도 수십 개의 프로필이 동일한 호스트 머신에서 서로 다른 "장치"로 존재하여 동일한 티어를 제공합니다.
이것이 파싱 스택에 어떤 변화를 주는가
헤드리스 브라우저를 대량으로 실행하는 사람들을 위한 몇 가지 실용적인 결과입니다.
- 컨테이너는 호스트를 상속합니다. Docker의 브라우저는 cgroup의 제한이 아니라 호스트 머신의 코어를 인식합니다. 즉, 하나의 고성능 서버에서 열 개의 컨테이너가 동일한 최대 티어를 제공합니다. 사용자 에이전트에서 열심히 그린 프로필의 다양성은 하드웨어 수준에서 존재하지 않습니다.
- 저렴한 VPS가 이제 더 눈에 띕니다. 두 개의 vCPU는 첫 번째 티어이며, Windows의 데스크톱 Chrome에서 첫 번째 티어는 실제 사람들에게는 드물게 나타납니다. 이전에는 약한 서버가 단순히 느렸지만, 이제는 눈에 띄게 표시됩니다.
- 신호는 사이트에 무료입니다. 타이밍 벤치마크와 같은 무거운 검사는 사용자의 시간을 소모하기 때문에 선택적으로 포함됩니다. 속성을 읽는 것은 비용이 들지 않으므로, 이전에 IP 평판 및 헤더로 제한되었던 사이트에서도 기본 세트에 추가될 것입니다.
- Compute Pressure와 함께 사용됩니다. Chrome의 릴리스 노트에서는 새로운 API를 Compute Pressure API와 결합할 것을 직접 제안합니다. 즉, "하드웨어 클래스 및 관찰된 부하"의 조합은 원래 표준 시나리오로 설계되었으며, 안티봇은 아무것도 발명할 필요가 없습니다.
하나의 "좋은" 프로필을 한 번 수집하고 수년간 재사용하는 것으로 충분하다는 가정은 별도로 재검토할 필요가 있습니다. 브라우저는 최종 사용자에게 알리지 않고 이러한 속성을 추가합니다: Chrome 152의 릴리스와 첫 번째 공개 분석 사이에는 수 주가 걸렸으며, 이 기간 동안 프로필은 아무것도 모르고 새로운 필드를 제공했습니다. 필드 세트를 검토하는 것은 연간 한 번이 아니라 릴리스 주기마다 한 번 하는 것이 좋습니다.
실제로 무엇을 해야 하는가
- 현재 값을 기록하십시오. 프로필 콘솔에서:
navigator.cpuPerformance,navigator.hardwareConcurrency,navigator.deviceMemory및 WebGL 렌더러 문자열. 네 개를 함께 기록하고, 하나씩 기록하지 마십시오 — 당신은 정확히 그 조합으로 검사를 받을 것입니다. - 티어를 프로필 전설과 비교하십시오. 모바일 전설은 첫 번째–세 번째 티어, 저가형 노트북은 두 번째–세 번째, 플래그십 데스크톱은 네 번째입니다. 구형 Android로 위장한 티어 4 또는 M 시리즈의 MacBook으로 위장한 티어 1은 모두 의심스럽습니다.
- 속성을 직접 수정하지 마십시오.
Object.defineProperty를 통한 대체는 getter 재정의의 흔적과 실제 실행 속도와의 불일치로 감지됩니다. 수정해야 한다면 브라우저 빌드 수준에서 하거나 내장된 메커니즘을 통해 하십시오. - 합법적인 오버라이드를 기억하십시오. Chrome은 사용자에게 설정에서 핸들을 제공하며(성능 → 속도 → CPU 성능 티어 오버라이드), 관리자에게는 기업 정책을 제공합니다. 이는 양측에서 유용한 정보입니다: 값은 "진짜"일 수도 있고 수동으로 설정된 것일 수도 있으며, 프로필 풀에서 대량으로 동일한 오버라이드가 발생하면 그것 자체가 표시가 됩니다.
- 프로필을 서로 다른 하드웨어에 분산하십시오. 모든 프로필이 동일한 서버에 있다면, 그들의 티어는 동일할 것입니다 — 그들이 어떤 장치를 나타내든지 간에. 이는 여러 구성의 기계로 이루어진 공원이 문제를 정직하게 해결하는 경우입니다.
같은 계열의 이웃 신호에 대한 자세한 내용은 장치 메모리 용량에 따른 지문 분석에서 확인할 수 있으며, 이러한 속성으로 작동하는 스텔스 브라우저에 대한 벤치마크는 nodriver, Camoufox 및 Patchright에서 확인할 수 있습니다.
여기서 프록시는 무엇인가
솔직히 말하자면: 프록시는 브라우저의 지문을 수정하지 않습니다. cpuPerformance는 클라이언트 측에서 계산되며, 어떤 IP도 이를 변경할 수 없습니다. 그러나 안티봇은 여러 레이어의 합계에 따라 결정을 내리며, 레이어의 경계에서 실패가 발생하는 경우가 많습니다.
저렴한 설정이 무너지는 전형적인 체인은 다음과 같습니다: 알려진 호스팅 네트워크의 IP, 프로세서의 첫 번째 티어, JS의 헤드리스 신호 — 각 신호는 개별적으로는 용인되지만, 함께 합쳐지면 명확한 판결을 내립니다. 이 합계에서 네트워크 레이어를 제거하는 것은 브라우저 필드와 싸우는 것보다 저렴하고 신뢰할 수 있습니다: 주거 IP에서 요청은 일반 가정 제공업체의 트래픽처럼 보이며, "데이터 센터" 가설은 감지기에서 자동으로 사라집니다. 모바일 전설의 경우도 마찬가지입니다 — 모바일 프록시는 모바일 프로필을 지원해야 하며, 그렇지 않으면 모순이 프로세서에서 네트워크로 이동합니다.
간단히 말해서
Chrome 152는 새로운 지문을 추가한 것이 아니라 교차 검증 테이블에 새로운 행을 추가했습니다. 두 개의 비트는 그 자체로는 아무도 드러내지 않지만, 불일치가 드러납니다: 선언된 장치는 프로세서 클래스, 메모리 용량, 그래픽 카드, 실행 속도 및 요청이 온 네트워크와 일치해야 합니다. 이번 주 프로필 감사는 콘솔의 한 줄과 "이런 하드웨어가 우리가 주장하는 것과 실제로 존재하는가?"라는 질문으로 시작해야 합니다.