Online Assessment Integrity and Anti-Cheating: A Progressive Model for a Consumer Math App

Threat model table

Angriff	Wer führt ihn aus	Wie erkennbar	Kosten zur Abwehr
Nachschlagen der Antwort (Suche, Lehrbuch)	Alle Alters‑/Stufen	Reaktionszeit weit unter der schnellstmöglichen plausiblen menschlichen Lösungszeit; nahezu sofortige Korrektheit nach sichtbarer Inaktivität/Tab‑Verdeckung	Niedrig — serverseitige Mindest‑Reaktionszeit pro Aufgabe, Tab‑Sichtbarkeits‑Ereignisse
Elternteil/Geschwister löst es für das Kind	Meist junge Kinder	Stilabweichung gegenüber der eigenen Fähigkeits‑Trendlinie des Kontos	Niedrig‑mittel — nur Trend‑basiertes Flag, nie strafend in diesem Alter
Solver‑App / Taschenrechner auf einem zweiten Gerät	Ältere Kinder, Jugendliche, Erwachsene	Mindest‑Reaktionszeit; ein Solver liefert nahezu sofortige Antworten unabhängig von der Schwierigkeit, während die menschliche Zeit skaliert	Niedrig‑mittel — gleiche Mindest‑Reaktionszeit‑Mechanik, pro Aufgabentyp kalibriert
Zweites Gerät antwortet, während das primäre Gerät der „Timer“ ist	Jugendliche, Wettbewerbs‑Stufe	Schwer ohne Geräte‑Attestierung; strukturell gemindert, indem das Timing serverseitig bleibt, sodass ein zweites Gerät keinen messbaren Vorteil erhält	Mittel — architektonisch, nicht als Zusatz‑Check
Antworten zwischen Freund*innen teilen	Alle Altersgruppen, Klassenkontexte	Antwort‑Ähnlichkeits‑/Kollusions‑Statistiken (Omega, GBT, K‑Index); erst bei großem Aufgabenkatalog sinnvoll	Mittel‑hoch — erfordert einen echten Katalog plus statistische Infrastruktur
Automatisierte Skripte/Bots (API‑Replay, headless Browser)	Technische Nutzer, Ranglisten‑Farmer	Bot‑Management‑Signale (Verhaltens‑Fingerprint, Proof‑of‑Work, TLS/JA3), Ratenbegrenzung, Turnstile/Privacy‑Pass‑Tokens	Niedrig‑mittel — fertige Infrastruktur
Account‑Sharing (ein Login, viele Personen)	Familien, Wettbewerbs‑Stufe	Erkennung gleichzeitiger Sitzungen, WebAuthn‑Anmelde‑Mismatches, Fähigkeits‑Diskontinuität	Mittel — erfordert Sitzungs‑/Geräte‑Tracking
Absichtliches Durchfallen einfacher Inhalte zum Rang‑Farmen („Sandbagging“)	Wettbewerbs‑/Ranglisten‑Nutzer	Varianz‑Anomalie gegenüber eigener Historie	Mittel — erfordert eine gepflegte Fähigkeits‑/Rating‑Basis (bereits gefordert in Thema 18)

Ergebnisse

1. Server‑authoritative Bewertung und warum Client‑Timing nicht vertrauenswürdig ist

Ein Browser ist vom eigenen Nutzer vollständig einseh‑ und veränderbar: DevTools können die Ausführung pausieren, Variablen umschreiben, bearbeitete Netzwerk‑Requests erneut abspielen und Date.now()/performance.now() überschreiben. Das ist dasselbe Bedrohungsmodell, das „client‑authoritative“ Mehrspieler‑Architekturen (der Client meldet seine eigene Punktzahl/Zeit, der Server glaubt ihr einfach) obsolet gemacht hat. Der Server muss Fragen‑Auslieferungs‑ und Antwort‑Empfangszeitstempel unabhängig setzen und die Korrektheit eigenständig prüfen – der Client rendert und sammelt nur. Nichts anderes skaliert zu einer Rangliste, bei der Geschwindigkeit Punkte bringt, da eine vom Client gemeldete Dauer genau das ist, was die meisten Belohnungen manipuliert.

2. Strategie für Item‑Banken: Größe, Parametrisierung, Randomisierung, Expositions‑Kontrolle

Die CAT‑Forschung liefert ein unmittelbar anwendbares Handbuch. Item‑Exposition — der Anteil der Prüflinge, die ein bestimmtes Item sehen — konvergiert bei den informativsten Items in einem naiven adaptiven Algorithmus gegen 1, was selbst ein Sicherheitsproblem darstellt: ein wiederholt gezeigtes Item wird teilbar [10]. Drei etablierte Gegenmaßnahmen: die Sympson‑Hetter‑Methode (eine Zufallszahl ziehen, sie mit einem pro‑Item‑Expositions‑Parameter vergleichen, bevor selbst das am besten passende Item eingesetzt wird); randomesque/stratifizierte Auswahl (zufällig unter den Top‑5‑10 informativsten Items wählen, nicht immer das einzig beste); und Shadow‑Testing (van der Linden — bei jedem Schritt einen vollständigen hypothetischen optimalen Test bauen, um global und nicht nur lokal optimale Entscheidungen zu treffen) [10]. Unter allen drei liegt ein großer Item‑Pool, der kostengünstig durch parametrisierte/algorithmische Item‑Generierung (eine Vorlage wie a + b = ? mit zufälligen Operanden pro Schwierigkeitsband) anstelle von handgefertigten Items wächst – ausdrücklich die praktische Methode, Pools wirtschaftlich gemäß der CAT‑Literatur zu vergrößern [10].

3. Statistische Erkennung: Ausreißer bei Reaktionszeit

Van der Linds lognormal‑Modell für Reaktionszeiten behandelt die Antwortzeiten einer Person auf Items als gesteuert durch einen personenbezogenen „Geschwindigkeits“-Parameter neben itembezogenen Zeit‑Intensitäts‑ und Diskriminations‑Parametern, strukturell analog zu dem, wie das zweiparametrige logistische IRT die Korrektheit behandelt [11]. Angepasst unterstützt es klassische und bayessche posterior‑prädiktive Prüfungen für aberrance — eine Antwort, die deutlich schneller oder langsamer als vorhergesagt ist — und wird bereits eingesetzt, um anomales Verhalten bei computerisierten adaptiven Tests zu erkennen [11]. Für Math Challenge benötigt die praktische Version zunächst nicht das vollständige Modell: ein empirischer Schwellenwert („kein verifizierter Mensch löst diese Item‑Klasse unter X ms“) ist eine legitime erste Verteidigungslinie, die erst bei Stufen, bei denen das Risiko den Aufwand rechtfertigt, auf das umfassendere Modell erweitert wird.

4. Statistische Erkennung: Antwort‑Ähnlichkeit und Kollusions‑Indizes

Die Erkennung von Antwort‑Kopieren/Kollusion ist ein etabliertes psychometrisches Teilgebiet, bestätigt über ERIC: Wollacks Omega (Ω)‑Index (verfeinert von Maeda & Zhang 2017; Sunbul & Yormaz 2018), der generalized binomial test (GBT) im Vergleich zu Omega hinsichtlich Power/Typ‑I‑Fehler (Zopluoglu & Davenport, 2012), der K‑Index (Holland) gegenüber Kullback‑Leibler‑Divergenz (Belov & Armstrong, 2010; Ucar & Dogan, 2021), ein auf Reaktionszeit basierendes KL‑Maß (Man et al., 2018) und ein Variable Match Index (Belov, 2011) [12]. Alle teilen eine Struktur: Sie markieren, wenn zwei Prüflinge die gleiche falsche Antwort häufiger geben, als der Zufall angesichts ihrer individuellen Fähigkeit vorhersagt – eine ungewöhnlich hohe Rate identischer falscher Antworten ist das Merkmal. Das ist nur sinnvoll, sobald eine Item‑Bank groß genug ist, dass das zufällige Zusammentreffen zweier Personen auf demselben Item selten ist.

5. Lockdown‑Browser und Remote‑Proctoring — und warum sie nicht bei Kindern eingesetzt werden sollten

Kamerabasiertes Remote‑Proctoring (Proctorio, ExamSoft, Honorlock, Respondus) nahm während COVID‑19 stark zu und hinterließ eine dokumentierte Spur von Schaden und juristischen Rückschlägen:

• Die Wirksamkeit ist zweifelhaft. Forschungen der Universität Twente werden (über eine sekundäre Zusammenfassung) berichtet, dass die Cheaterkennungs‑Sensitivität von Proctorio „sehr nahe bei null“ liegt [4].
• Ein US-Bundesgericht befand eine bestimmte Praxis für verfassungswidrig. Ogletree v. Cleveland State University betraf einen vorgeschriebenen Webcam‑„Raum‑Scan“; der Fall ist als Entscheidung zum vierten Verfassungszusatz gegen die Praxis von einem Bundesbezirksgericht in Ohio (2022) dokumentiert [3].
• Illinois‑BIPA‑Prozess. Studierende behaupteten, Proctorio habe biometrische Informationen/Identifikatoren ohne erforderliche Einwilligung gesammelt; Proctorio wies die Vorwürfe zurück. BIPA sieht gesetzliche Schadensersatzbeträge von 1.000 $ (fahrlässig) / 5.000 $ (absichtlich) pro Verstoß vor, weshalb Proctoring‑Anbieter immer wieder mit solchen Klagen konfrontiert werden [13].
• Der oft zitierte niederländische Fall verläuft in die andere Richtung. Rechtbank Amsterdam, ECLI:NL:RBAMS:2020:2917 (11 Juni 2020): Die Zentral‑ und Fakultäts‑Studentenräte der UvA beantragten eine einstweilige Verfügung gegen Proctorio; das Gericht wies alle Ansprüche zurück und befand die Verarbeitung gemäß GDPR Art. 6 (1) (e) als rechtmäßig, „notwendig“ angesichts der COVID‑19‑Schließungen, „proportional“ (automatisierte Vorselektion, begrenzte menschliche Prüfung, 30‑Tage‑Löschung) und „angemessen gesichert“ (EU‑Speicherung, Auftragsverarbeitungs‑Vereinbarung, DPIA vorliegend), wobei Proctorio als „weniger invasiv als kontinuierliche Live‑Video‑Überwachung“ bezeichnet wurde [5]. Es ist ein echter gerichtlicher Sieg für Proctoring – jedoch nur unter der Bedingung eines engen, dokumentierten Schutzpakets (kurze Aufbewahrung, DPIA, erwachsene Studierende, pandemiebedingte Notwendigkeit), das nichts über eine Verbraucher‑App für Vierjährige aussagt.
• Ein paralleles Diskriminierungsurteil. Die VU Amsterdam sah sich separat einer Beschwerde des niederländischen Instituts für Menschenrechte gegenüber, die behauptete, Proctorio habe einen schwarzen Studierenden diskriminiert; das Institut stellte in diesem Fall keine Diskriminierung fest, die Beschwerde fügt sich jedoch in das gleiche breitere Muster von Bedenken hinsichtlich algorithmischer Voreingenommenheit bei Proctoring ein (unverified über das kurze Zitat hinaus).

Fazit für Math Challenge: Kamera‑/Mikrofon‑Proctoring von Kindern hat in diesem Produkt auf keiner Stufe Platz. Die dokumentierten Schäden wirken bei Minderjährigen stärker als bei den universitären Erwachsenen, die in den Fällen betroffen waren, und keine der mildernden Bedingungen des Amsterdamer Gerichts (Pandemie‑Notwendigkeit, Einwilligungsfähigkeit Erwachsener, institutionelle DPIA) sind hier gegeben.

6. Geräte‑Attestierung im Web im Jahr 2026

• WebAuthn/Passkeys: standardisierte Browser‑API, funktioniert in jedem modernen Browser einschließlich installierter PWAs; bindet ein Public‑Key‑Credential an ein Gerät, und ein Server kann mehrere Credential‑IDs pro Konto speichern — WebAuthn selbst kennzeichnet ein „neues Gerät“ nicht automatisch, diese Buchführung erfolgt serverseitig [16].
• Private Access Tokens (Apple) / Privacy Pass (IETF): ein Drei‑Partei‑Schema (Issuer, Client, Server), das beweist, dass eine Anfrage von einem legitimen Gerät stammt, ohne die Identität preiszugeben, mittels Challenge‑Response‑Ablauf und RSA‑Blind‑Signatur‑Validierung; in iOS 16+/macOS Ventura+ integriert, um CAPTCHAs zu reduzieren, und in Cloudflare Turnstile eingebunden — aber keine bestätigte First‑Class‑Unterstützung außerhalb von Apple‑Plattformen, daher als Bonus‑Signal für Safari/iOS‑Traffic zu behandeln, nicht als allgemeiner Mechanismus [14][15][18].
• Google Play Integrity API: ausschließlich für native Android‑Apps, die über Google Play verteilt werden, prüft die Authentizität des App‑Binaries, die Installationsquelle und die Echtheit des Geräts — gilt nicht für eine PWA; Googles eigene Web‑Richtlinien verweisen anderweitig (Privacy Sandbox) [17].
• Apple App Attest: analoges native‑iOS‑Attestationsverfahren, an die App‑Store‑Distribution gebunden, wie Play Integrity an den Play Store gebunden ist — für eine PWA, die nicht über den App Store verteilt wird, nicht verfügbar.

Praktische Schlussfolgerung für ein PWA‑first‑Produkt: WebAuthn ist das einzige gerätebindende Primitive, das wirklich überall verfügbar ist; Play Integrity/App Attest sind strukturell ohne native Wrapper‑Apps nicht anwendbar; Private Access Tokens sind ein echtes, aber Apple‑lastiges Bonus‑Signal, das bereits in Turnstile integriert ist.

7. Bot‑Erkennung und Rate‑Limiting

Cloudflares Bot‑Management‑Stack kombiniert eine ML‑Engine, die jede Anfrage anhand von Request/Header/Session‑Merkmalen mit einem Score von 1‑99 bewertet, eine heuristische Engine, die bekannte bösartige Fingerabdrücke abgleicht, und eine JavaScript‑basierte Erkennung von headless‑Browsern, verfeinert durch ein Session‑Cookie (__cf_bm), das die Scores glättet, um Fehlalarme zu reduzieren [18]. Turnstile ist die verbraucherorientierte Version: kleine nicht‑interaktive JS‑Challenges (Proof‑of‑Work, Proof‑of‑Space, Web‑API‑Abfrage, Browser‑Quirk‑Erkennung) anstelle eines visuellen Puzzles, das bereits Privacy‑Pass‑Tokens als einen Input behandelt [15][18]. Rate‑Limiting auf Einreichungs‑/Scoring‑Endpunkten ist die einfachere ergänzende Ebene: Das Begrenzen von Einreichungen pro Konto/IP/Zeitfenster fängt hochvolumige skriptgesteuerte Angriffe ab, unabhängig davon, ob eine einzelne Anfrage menschlich wirkt.

8. Wie benannte Wettbewerbsplattformen Cheating in großem Maßstab handhaben

• Codeforces: bewertet die Leistung relativ zu Gegnern mit bekannter Wertung innerhalb eines Wettbewerbs statt fester Punkte pro Aufgabe, wodurch der Anreiz, einen reinen Punktwert zu manipulieren, reduziert wird (siehe Thema‑18‑Forschung, docs/research/2026-07-31-mc-18-leaderboards-competition.md) [1].
• Chess.com: erkennt verdächtiges Spiel anhand von „über 100 Gameplay‑Faktoren“ und verlässt sich ausdrücklich nicht auf einen einzelnen Genauigkeitswert („Accuracy is not cheat detection“); automatisierte Systeme bearbeiten ~85 % der Schließungen; Jan‑Mär 2025 wurden ~28.000 Einsprüche von 314.000 Schließungen mit einer Gewährleistungsrate von 0,2 % geprüft; obligatorische Zwei‑Kamera‑Proctor‑Software ist nur für Veranstaltungen mit Geldpreisen erforderlich; die Methodik wurde extern von dem Harvard‑Statistiker Natesh S. Pillai (2016) geprüft und von US Chess (2020) unterstützt [2].
• Duolingo: bekämpft Leaderboard‑/XP‑Farming (automatisch abschließende Bots, wiederholtes Inhalts‑Farming, Timing‑Ausnutzungen), indem ungewöhnliche XP‑Spitzen und unrealistisch schnelle Lektionen‑Abschlüsse überwacht werden, unterstützt durch Sperren und Community‑Meldungen — das Prinzip der Reaktionszeit‑Ausreißer wird informell im Produktmaßstab angewendet [19].
• Kaggle: Die Regeln sind branchenweit bekannt, um privates Teilen außerhalb von Teamgrenzen zu beschränken, Teamgrößen‑/Fusion‑Zeiträume zu begrenzen und Mehrfachkonten zu verbieten, aber die Details dieses Abschnitts sind allgemeines Branchenwissen, keine bestätigte Quelle (Dokumentation war während dieser Forschung nicht direkt zugänglich).
• Kahoot: Es konnte keine zitierbare Primärquelle zu Betrug/Bot‑Werkzeugen (z. B. Drittanbieter‑„Flooder“-Skripte) gefunden werden; dies bleibt eine offene Lücke, kein belegter Anspruch.

Designimplikationen

Eine konkrete, sechsstufige progressive Leiter. Jede Stufe fügt nur weitere Kontrollen zur server‑authoritativen Basis der vorherigen Stufe hinzu — es wird nichts entfernt, wenn man aufsteigt, und nichts über Stufe 0 wird jemals auf die Stufe eines jüngeren Kindes herabgedrängt.

1. Tier 0 — Kinder (4‑6): ausschließlich server‑authoritative Zeit‑/Punktvergabe, unsichtbar. Der Server versieht jede gestellte Frage und jede empfangene Antwort eigenständig mit Zeitstempel und prüft die Richtigkeit; der Client steuert keinen der Werte. Keine sichtbare Anti‑Cheat‑UI, kein Lockout, keine Betrugs‑Nachricht — ein Elternteil, der zusammen mit dem Kind löst, ist der vorgesehene Anwendungsfall, keine Bedrohung.
2. Tier 0 — Reaktionszeit‑Mindestwert, nur Protokollierung. Für jeden Aufgabentyp wird die minimal plausible Lösungszeit erfasst und protokolliert, wenn sie unterschritten wird, ohne jemals zu blockieren oder null Punkte zu vergeben. Reine Telemetrie zur Kalibrierung späterer Stufen; erscheint nur in einem zukünftigen Eltern‑/Erziehungsberechtigten‑Dashboard, nie für das Kind.
3. Tier 1 — Frühe Grundschule (7‑9): stilles Varianz‑Monitoring. Der Server verfolgt den Genauigkeits‑/Geschwindigkeits‑Trend jedes Lernenden pro Fähigkeit; eine plötzliche große Abweichung löst nur ein sanftes Signal aus (leicht vorsichtigere adaptive Schwierigkeit) — nie ein Lockout, keine Warnung und keine sichtbare Strafe.
4. Tier 1 — Ratenbegrenzung bei Einreichungs‑Endpoints. Grundlegende Einreichungs‑Limits pro Konto/IP (gemeinsame Infrastruktur) schützen das Backend vor skriptbasiertem Missbrauch ab dieser Stufe aufwärts.
5. Tier 2 — Späte Grundschule/Mittelschule (10‑13): Reaktionszeit‑Mindestwert wird zu einem aktiven, sanften Signal. Das Unterschreiten des Mindestwerts löst einen freundlichen UI‑Hinweis aus („Das war schnell — noch einmal prüfen?“) statt eines stillen Logs; wiederholte Verstöße senken das Vertrauen in die Beherrschungs‑Schätzung, aber Punkte werden nie annulliert. Immer noch kein Lockout, keine Proctoring‑Maßnahme, keine elterliche Alarmierung.
6. Tier 2 — Randomisierung des Aufgabepools wird relevant. Parametrisierte Aufgabengenerierung (zufällige Operanden pro Schwierigkeitsband) wird zum Standard‑Auslieferungsmechanismus, da dies das Alter ist, in dem ein Geschwisterkind oder Klassenkamerad erstmals einen Anreiz hat, ein exakt gleiches Aufgabenset weiterzugeben.
7. Tier 3 — Oberstufe/Allgemeine Teenager (14‑17): Turnstile + WebAuthn‑Gerätebindung nur für Leaderboard‑Aktionen. Turnstile schützt die Leaderboard‑relevanten Einreichungs‑Endpoints (standardmäßig unsichtbar); WebAuthn‑Geräte‑Credentials werden zur Kontenerkennung eingeführt, nicht als Login‑Voraussetzung — das Markieren von „ein drittes neues Gerät diese Woche“ ist ein Eingabefaktor, niemals ein alleiniges Hindernis.
8. Tier 3 — Reaktionszeit‑ und Antwort‑Ähnlichkeits‑Statistiken aktivieren, nur im Leaderboard‑Umfang. Sobald der Aufgabepool groß genug ist (Finding 4), führt der Server eine einfache Reaktionszeit‑Ausreißer‑Prüfung (Finding 3) durch und, wenn Konten genügend gemeinsame Aufgaben teilen, eine Antwort‑Ähnlichkeits‑Prüfung nach den veröffentlichten Indizes — beschränkt auf Leaderboard‑Aktivität, nicht auf reguläres Üben.
9. Tier 4 — Fortgeschritten/Pre‑Competitive (16 +, freiwillig im Rang‑Spiel): vollständige Kontrolle der Aufgabenaussetzung. Sympson‑Hetter‑artige Expositionsbegrenzung (Finding 2) begrenzt, wie häufig selbst die am besten passende nächste Aufgabe Nutzern ähnlicher Fähigkeit gezeigt wird, und schützt den „jeder in diesem Rang bekommt dieselbe nächste Aufgabe“-Sharing‑Vektor, der bei echten Einsätzen relevant wird.
10. Tier 4 — Sitzungs‑/Konto‑Sharing‑Heuristiken werden aktiv, nicht nur protokolliert. Die Erkennung gleichzeitiger Sitzungen und Fähigkeits‑Diskontinuitäts‑Markierungen erhöhen nun aktiv die Bewertungs‑Volatilität/RD (wie ein verdächtiges neues Konto), statt nur in einem Dashboard zu erscheinen.
11. Tier 5 — Wettbewerbs‑/Stipendien‑berechtigte Spitzenstufe (opt‑in, explizite Einsätze, elterliche Zustimmung bei Minderjährigen): die vollständige statistische Suite, weiterhin ohne Kameras. Die veröffentlichte psychometrische Maschinerie (Omega/GBT‑Stil Kollusions‑Erkennung, das umfassendere lognormale Reaktionszeit‑Modell) rechtfertigt hier die Kosten, da der Pool groß und die Einsätze hoch sind. Selbst auf dieser Ebene bleibt die Antwort mehr Statistik, niemals eine Webcam, ein Lockdown‑Browser oder biometrische Erfassung — Finding 5 liefert kein Szenario, in dem Kamera‑/biometrisches Proctoring eines Minderjährigen oder eines Erwachsenen ohne institutionelle Vorgabe vertretbar wäre.
12. Server‑seitig vs. client‑seitig, in jeder Stufe, ohne Ausnahme. Client‑seitig immer: Darstellung der Aufgabe, Erfassung der Antwort, lokales UI‑Feedback. Server‑seitig immer, ab Stufe 0: das Zeitstempel‑Paar, die Richtigkeitsprüfung, die Punktzahl und (ab Stufe 3) jedes statistische Signal in Findings 3‑4 und 7. Die Autorität für Zeit und Richtigkeit wechselt in keiner Stufe zum Client — die Leiter ist progressiv in den Einsätzen, nicht im Vertrauen zum Client, das niemals gewährt wird.
13. Was wir einem Kind in keiner Stufe bewusst niemals tun werden. Keine Aufnahme per Webcam oder Mikrofon. Keine Erfassung biometrischer Daten (Gesicht, Stimme, Tastenanschlag‑Dynamik, Blickverfolgung). Kein Lockdown‑Browser. Kein Fern‑Human‑Proctor. Keine Punktabzug‑ oder Konten‑Aktion, die einem Kind unter Stufe 3 sichtbar ist — unter Stufe 3 sind Signale reine Kalibrier‑Telemetrie und höchstens ein Eintrag im Eltern‑/Erziehungsberechtigten‑Dashboard. Keine strafende Formulierung („du wurdest beim Schummeln erwischt“) irgendwo — das schlechteste sichtbare Ergebnis in jeder Stufe ist eine geringere Vertrauenswürdigkeit der Beherrschungs‑Schätzung oder ein freundlicher Hinweis, passend zum festgelegten Design: Anti‑Cheating bleibt für kleine Kinder nahezu unsichtbar und wird erst bei steigenden Einsätzen strenger.

Offene Fragen für den Projektinhaber

1. In welchem Alter/ welcher Stufe, falls überhaupt, sollte ein elterliches Dashboard Anomaliesignale (Stufen 1‑2) anzeigen — und sollte es jemals dem Kind, auch indirekt, sichtbar sein?
2. Wird Math Challenge irgendeine Veranstaltung mit realen Einsätzen (Stipendium, Geldpreis, schulisch anerkannter Wettbewerb) durchführen, die die vollständige statistische Suite von Stufe 5 rechtfertigt, oder bedeutet „Wettbewerbs‑Stufe“ nur Ranglisten‑Prestige?
3. Sollte die Einführung von WebAuthn/Passkey jemals verpflichtend sein, oder immer optional, da es das einzige universelle Geräte‑Bindungs‑Primitive ist, aber bei einem Konto eines kleinen Kindes Reibung erzeugt?
4. Wie können die Sitzungs‑Heuristiken ab Stufe 4 bei legitimer Familien‑Konto‑Nutzung (Eltern‑ und Kind‑Login) verhindern, dass normales Geräte‑Wechseln innerhalb der Familie fälschlich als verdächtig markiert wird?
5. Gibt es Interesse, eine Vertrauens‑/Sicherheits‑Erklärung zu veröffentlichen, dass Math Challenge niemals Webcam‑/biometrisches Proctoring einsetzt, als Unterscheidungsmerkmal zu Proctorio‑artigen Produkten und als Vertrauenssignal für Eltern?