---
type: explanation
title: 계측
summary: Caputchin이 챌린지를 스크립트가 아니라 진짜 브라우저가 풀었는지 어떻게 확인하는지.
---

Proof of work는 *노력*이 들었음을 증명합니다. 그것은 *무엇*이 그것을 들였는지는 증명하지 않습니다. 진짜 브라우저 농장을 가진 작정한 공격자는 퍼즐을 싸게 갈아낼 수 있습니다. 계측은 그 간극을 닫는 두 번째 계층입니다: 그것은 그 일이 진짜 브라우저 안에서 일어났음을 증명합니다.

## 동작 방식

모든 요청에서, Caputchin은 갓 만든 일회성 JavaScript 프로그램을 생성해 방문자의 브라우저에서 돌립니다. 그 프로그램은 진짜 브라우저만 가진 기계를 가동하고, 자기가 관찰한 것을 보고합니다:

- 진짜 브라우저 기능이 있고 올바르게 동작하는지 확인하는 **브라우저 API 탐침**.
- 비트 단위 정수 연산의 **연산 사슬**.
- 요소의 트리를 짓고, 레이아웃 엔진이 그것들에 대해 계산하는 값을 읽고, 그것들을 도로 헐어 내리는 **DOM 산술**.

요령은 비대칭입니다: 진짜 렌더링 엔진은 거의 공짜로 맞는 답을 내는 반면, 헤드리스나 스크립트 런타임은 이 연산을 스텁으로 처리하거나, 잘못 구현하거나, 속도를 위해 건너뜁니다. 그 불일치가 방문자를 들통나게 합니다.

## Content-Security-Policy

프로그램이 방문자의 브라우저에서 `eval`을 돌리므로, 당신의 위젯을 임베드하는 페이지는 그 `script-src` Content-Security-Policy에서 `'unsafe-eval'`을 허용해야 합니다. 이것에는 대체가 없습니다: `'unsafe-eval'`이 차단되면, 프로그램이 돌 수 없고 검증이 실패합니다. 당신의 정책이 그것을 허용할 수 없다면, 키의 [보안](/docs/site-keys/security) 페이지에서 계측을 끄세요, 그것은 자동화 브라우저 탐지를 대가로 그 요건을 떨굽니다(proof of work와 모든 필수 게임은 여전히 돕니다). 전체 호스트 페이지 정책은 [게임 샌드박싱](/docs/understanding-caputchin/game-sandboxing#the-csp-you-set-on-your-own-page)을 보세요.

## 왜 proof of work와 짝짓는가

두 계층은 서로의 사각을 덮습니다. Proof of work만으로는 진짜 브라우저가 싸게 채굴할 수 있고; 계측만으로는 그 일을 결코 하지 않는 스크립트가 위조할 수 있습니다. 함께 그것들은 두 독립 축에서 비용을 올립니다: proof of work는 노력을 증명하고, 계측은 환경을 증명합니다.

## 난독화

프로그램이 방문자에게 출하되므로, 동기 있는 공격자가 그것을 연구해 답을 미리 계산하려 들 수 있습니다. 그것을 더 어렵게 하려고, 프로그램은 난독화됩니다. 키의 [보안](/docs/site-keys/security) 페이지는 **난독화 수준**을 노출합니다: 그것을 올리면 더 많은 서버 측 CPU를 대가로 프로그램이 역공학하기 더 어려워집니다. 같은 신호가 탐지된 헤드리스와 WebDriver 클라이언트를 단호히 거부하는 **자동화 브라우저 차단** 옵션을 뒷받침합니다.

## 정직한 한계

계측은 완벽하지 않습니다. 스텔스 브라우저는 그것이 찾는 단서를 패치하고, 확인 자체도 깨질 수 있다고 적습니다. 그것은 여럿 중 한 계층이며, [proof of work](/docs/understanding-caputchin/proof-of-work)와 키의 나머지 [보안](/docs/site-keys/security) 설정과 쌓일 때 가장 강합니다.