Fortress — Verifikation für Fancci

Jede Zahl auf dieser Seite stammt aus einem Prüfstand, der selbst fehlschlägt. Keine ist von Hand gepflegt. Alles hier ist reproduzierbar — die Befehle stehen daneben.

Ein Befehl rechnet alles nach

node sdk/verify-all.cjs            # alles, mit den Messläufen
node sdk/verify-all.cjs --schnell  # ~2 min, dann fehlen die Zahlen
node sdk/verify-all.cjs --json     # maschinenlesbar

Exit 0 = jeder ausgeführte Prüfstand grün. Ein Paket ohne Test wird als „KEIN TEST" gemeldet — nicht als bestanden.

Die Creator-Kette, durchgehend belegt

Markieren → Unsichtbarkeit messen → verteilen → finden → zuordnen → Dossier. Ein Lauf, sieben Stufen, jede mit Gegenprobe. Gemessen an einem echten Kamerafoto, 4608×3456 (15,9 MP).

node sdk/fortress-creator-e2e.cjs      # 32/32

1 · Unsichtbarkeit

Gemessen in ΔE00 (CIEDE2000) als schlimmstes 64×64-Fenster, Schwelle 1,0 — nie in dB und nie als Bildmittelwert. Ein Mittelwert kann einen lokalen Fleck strukturell nicht anzeigen.

MessungΔE00
schlimmstes 64×64-Fenster0,387Schwelle 1,0
glatteste Flächen (dort maskiert nichts)0,333
Kontrolle ohne Marke (nur 8-Bit-Rundung)0,021ohne sie misst das Instrument sich selbst
Pixel über der Schwelle0,065 %Maximum 1,59

Zwei Kriterien, beide genannt

Nach dem Fenster-Kriterium ist die Marke mit 0,387 deutlich unsichtbar. Nach dem strengeren Pixel-Kriterium des Instruments (kein einzelnes Pixel über der Schwelle) ist sie mit Maximum 1,59 grenzwertig. Beide Zahlen gehören zusammen zitiert; die Wahrheit ist die Spanne.

Zum Vergleich, dieselbe Messung: die älteren Profile stealth (7,47) und crop-hardened (6,60) sind nach beiden Kriterien sichtbar. Für einen Creator ist das unsichtbare Profil das einzig brauchbare — und genau das wählt die Fassade selbstständig.

2 · Nutzlast durch die Verteilung

StufeErgebnis
JPEG q85 (Web-Upload)Schlüssel gelesen → benannter Empfänger
JPEG q40 (starke Kompression)Schlüssel gelesen
auf 75 % verkleinert + JPEGSchlüssel gelesen
Gegenprobe: unmarkiertes Fotokein Schlüssel — ohne diese Zeile wäre jeder Treffer wertlos

3 · Der Fund und das Dossier

Der Crawler holt die Datei rechtmäßig: robots.txt zuerst, die erlaubende Regel im Protokoll, Inhalts-Hash, ausgelieferter Transport. Gegenprobe: verbietet robots.txt, wird nicht geholt.

Das Dossier trennt A. GEMESSEN (vom Code festgestellt) von B. ERKLÄRT (Angaben des Auftraggebers) von C. GRENZEN, enthält den signierten technischen Bericht und die einreichbare DSA-Art.-16-Meldung. Beispiel: sdk/FANCCI_CREATOR_DOSSIER_BEISPIEL.txt

Der Crawler

PrüfstandErgebnisBeantwortet
test.cjs77/77verhält er sich wie zugesagt?
rfc9309-test.cjs30/30liest er robots.txt wie die Norm?
robots-korpus-test.cjs32/32und wie echte Dateien von 12 realen Plattformen?
mutation.cjs --gate100 %würde die Suite es merken, wenn der Code kaputt wäre?

Warum der vierte Lauf der wichtigste ist

Hier stand einmal „53/53 ALL PASS". Ein Mutationstest baute 36 Fehler ein — 22 blieben unbemerkt, Score 39 %. „Alle Tests grün" ist keine Aussage, solange niemand geprüft hat, ob die Tests etwas merken.

Nebenbefund aus den 12 echten robots.txt: 7 von 12 Plattformen regeln KI-Crawler namentlich (GPTBot, ClaudeBot, CCBot, Google-Extended …). Kein einziger dieser Vorbehalte steht in einem TDM-Reservation-Header oder in tdmrep.json — die Norm beschreibt einen Kanal, den die Praxis nicht benutzt.

Multimodal: Video & Audio — selbst testen

Alle drei Modalitäten laufen live auf der AntiPiracy-Demo-Seite — Bild mit Profilwahl und Vorher/Nachher-Regler, Video mit echtem H.264-Durchgang, Audio mit A/B-Hörvergleich und MP3-128k-Angriff. Jede Zahl unten hat ihren Reproduktions-Befehl.

ModalitätGemessenGrenze (steht auch auf der Demo-Seite)
🎬 VideoUnsichtbar UND H.264-fest (Profil invisible, Marke im Luma-Mittelband): ΔE00 worst ≤ 0,82 < Schwelle 1,0 über 4 Inhaltstypen (glatt/dunkel/flach/schnelle Bewegung, jedes Bild angeschaut) · Schlüssel über Zeit-Mehrheit durch echtes Mehrframe-H.264 CRF23+28 (Per-Frame 30/30, schnelle Bewegung CRF28 26/30 → Voting fängt auf; node video-invisible-breadth.cjs) · Tonspur bleibt erhalten und wird mitfortresst (eine Datei, zwei Marken) Crop ist die verbleibende Grenze: die Kachel-Akkumulation braucht das ungeschnittene Raster (Rand-Crop bis 25 % übersteht, zentriert nicht) — in diesem unsichtbaren Modus nicht crop-/screenshot-fest · Fund erst ab ≥3 Frame-Stimmen — die nackte Mehrheits-Funktion benennt ab 1/24 (gemessen) · ein früherer Cb-Chroma-Weg wurde 2026-08-09 als sichtbar (ΔE00 14–28) zurückgenommen
🎧 AudioDurch echtes MP3 128k / AAC / Opus / Vorbis ausgelesen (npm run validate:audio); Demo-E2E inkl. MP3-Angriff grün · Embed jetzt energie-maskiert (R&D-Champion: min SNR 16,4 → 20,0 dB auf 3 echten Tracks, MP3 128k+64k intakt; Auslesen bleibt die unveränderte SDK) Hörbar bleibt es — die Bark/NMR-Messung zeigt: jede Margin-Formung bleibt +22…+49 dB über der Hörschwelle → „unhörbar“ wäre gelogen, deshalb A/B-Vergleich; „unhörbar“ bräuchte eine Frequenzbereich-Einbettung (R&D-Posten)
🖼 BildStandard: unsichtbar (invisible) — ΔE00 schlimmstes 64²-Fenster 0,73 < Schwelle 1,0, PSNR ~39 dB (gemessen 2026-08-11, 2 Realfotos @1024²); übersteht JPEG q50 · Resize 75 % · Recolor auf Foto-Material · Profilwahl unsichtbar/diskret/crop-gehärtet/Chroma-Vergleich, E2E lokal + live (node e2e.cjs) Unsichtbar: nicht Rand-Crop-fest (dafür crop-gehärtet, das sichtbar ist) · flache Grafik @1024²: JPEG-Grenze (1/2; nativ im SDK 12/12) · Diskret: texturierte Fenster ΔE00 bis 13,7–21,2 (sichtbar) · Chroma (14.05.): Demo-Linie, nicht die verkaufte SDK

Was hier ausdrücklich nicht behauptet wird

Crop: nur vom Rand

Gemessen: das unsichtbare Profil überlebt Crop aus der Ecke bis 25 % (2/5/10/25 % je gelesen), zentrierten Crop nicht — 4 von 8 Fällen. Der Grund ist Geometrie: die Akkumulation braucht das 256er-Kachelraster; ein Eck-Crop lässt es stehen, ein zentrierter verschiebt es.

Die ältere Aussage „CROP SOLVED — crop 10/25/50 % → 100 %" gilt nicht für den ausgelieferten Weg: sie entstand mit bekanntem Crop-Faktor, übergebenem Schlüssel und zurückgepolstertem Bild. Der blinde Pfad liefert 0/8. Korrigiert in BENCHMARK_TRUTH.md.

Plattformen: bei der Verteilgröße markieren

Bild-Ketten am Master markiert: 0/4. Bei Verteilgröße markiert: 2/4 (Telegram, Instagram). WhatsApp und Twitter/X: 0 in beiden. Video-Ketten: 4/4.

Wer am Master markiert und die Plattform herunterskalieren lässt, verliert die Marke — sie sitzt im L2-Mittelband, und eine Verkleinerung unter etwa die Hälfte löscht dieses Band. Die Ketten sind nachgebildet, keine Messung der Plattform: wir laden dort nichts hoch und crawlen dort nichts.

Auflösung, Mutationsscore, Fundlage

Unsichtbarkeit hängt an der Auflösung: bei 1536 px liegen 25,2 % der Pixel über der Schwelle, bei voller Auflösung 0,065 %. Der Schnellmodus ist kein Beleg.

Der Mutationsscore ist eine untere Schranke der Testgüte, kein Zeugnis — manche Mutanten sind äquivalent. Median über alle 13 offenen Pakete: 80 %, vier davon bei 100 %, sieben noch unter 90 %.

Kein Treffer ≠ kein Leak. Und ein Lauf mit übersprungenen Hosts ist keine Unbedenklichkeitsbescheinigung.

Die Ordnung — damit nichts doppelt gebaut wird

node sdk/inventory.cjs --check   # existiert etwas, das in keinem Dokument steht?
node sdk/coverage.cjs            # je Use Case: Encoding · Decoding · Prüfer · Seite
node sdk/honesty-check.cjs       # Regel 9 maschinell über alle offenen Pakete
node sdk/install-test.cjs        # laden die Pakete, wenn man sie wirklich installiert?

Deckung: 12/12 Use Cases mit Encoding, Decoding, offenem Prüfer und ausgelieferter Seite. Regel 9: 13/13. Installierbar: 14/14.

Was diese Seite nicht ist: kein Rechtsgutachten und keine anwaltliche Einschätzung. Das Dossier ist Beweismaterial; die rechtliche Bewertung, der Adressat und jede Forderung sind Sache des Anwalts.

Offline erzeugt, EU-souverän. Stand 2026-07-30.