---
type: explanation
title: Instrumentierung
summary: Wie Caputchin prüft, dass eine Aufgabe von einem echten Browser gelöst wurde, nicht von einem Skript, das vorgibt, einer zu sein.
---

Proof of Work beweist, dass *Aufwand* aufgewendet wurde. Es beweist nicht, *was* ihn aufwendete. Ein entschlossener Angreifer mit einer Farm echter Browser kann sich billig durch Rätsel mahlen. Instrumentierung ist die zweite Schicht, die diese Lücke schließt: sie beweist, dass die Arbeit in einem echten Browser geschah.

## Wie es funktioniert

Bei jeder Anfrage generiert Caputchin ein frisches, einmaliges JavaScript-Programm und führt es im Browser des Besuchers aus. Das Programm beansprucht Maschinerie, die nur ein echter Browser hat, und meldet zurück, was es beobachtet hat:

- **Browser-API-Sonden**, die prüfen, dass echte Browser-Funktionalität vorhanden ist und sich korrekt verhält.
- **Berechnungsketten** bitweiser Integer-Operationen.
- **DOM-Arithmetik**, die Bäume von Elementen baut, die Werte liest, die die Layout-Engine für sie berechnet, und sie wieder abbaut.

Der Trick ist eine Asymmetrie: eine echte Rendering-Engine produziert die richtigen Antworten fast umsonst, während eine Headless- oder skriptgesteuerte Laufzeit diese Operationen stubst, sie falsch implementiert oder sie für Tempo überspringt. Die Diskrepanz verrät den Besucher.

## Content-Security-Policy

Weil das Programm `eval` im Browser des Besuchers ausführt, muss die Seite, die dein Widget einbettet, `'unsafe-eval'` in ihrer `script-src`-Content-Security-Policy erlauben. Dafür gibt es keinen Fallback: ist `'unsafe-eval'` blockiert, kann das Programm nicht laufen und die Verifizierung schlägt fehl. Kann deine Policy es nicht erlauben, schalt die Instrumentierung für den Key auf seiner [Sicherheit](/docs/site-keys/security)-Seite aus, was die Anforderung auf Kosten der Automatisierte-Browser-Erkennung fallen lässt (Proof of Work und jedes verlangte Spiel laufen weiter). Sieh dir [Spiel-Sandboxing](/docs/understanding-caputchin/game-sandboxing#the-csp-you-set-on-your-own-page) für die vollständige Host-Seiten-Policy an.

## Warum es sich mit Proof of Work paart

Die zwei Schichten decken die blinden Flecken der jeweils anderen ab. Proof of Work allein kann von echten Browsern billig gemined werden; Instrumentierung allein könnte von einem Skript gefälscht werden, das die Arbeit nie tut. Zusammen erhöhen sie die Kosten auf zwei unabhängigen Achsen: Proof of Work beweist Aufwand, Instrumentierung beweist Umgebung.

## Verschleierung

Weil das Programm zum Besucher ausgeliefert wird, könnte ein motivierter Angreifer es studieren und versuchen, die Antworten vorzuberechnen. Um das schwerer zu machen, ist das Programm verschleiert. Die [Sicherheit](/docs/site-keys/security)-Seite eines Keys stellt eine **Verschleierungsstufe** bereit: sie hochzudrehen macht das Programm schwerer zu reverse-engineeren, auf Kosten von mehr serverseitiger CPU. Dieselben Signale stützen die Option **Automatisierte Browser blockieren**, die erkannte Headless- und WebDriver-Clients rundheraus ablehnt.

## Eine ehrliche Grenze

Instrumentierung ist nicht narrensicher. Stealth-Browser patchen die Verräter, nach denen sie sucht, und die Prüfungen selbst vermerken, dass sie geschlagen werden können. Sie ist eine Schicht unter mehreren, am stärksten, wenn sie mit [Proof of Work](/docs/understanding-caputchin/proof-of-work) und dem Rest der [Sicherheits](/docs/site-keys/security)-Einstellungen eines Keys gestapelt ist.