Dasselbe Smartphone, unterschiedliche Lernende

Ein Hinweis auf ein Limit ist kein Beleg für Missbrauch

Eine lernende Person schließt ein Quiz ab, kann die Prämie aber nicht anfordern. Auf dem Bildschirm steht, dass ein Limit gilt. Offen bleibt, für wen es gilt, welche Aktion gezählt wurde und wann der Zugriff wieder möglich ist.

Bei der Untersuchung eines Supportfalls kamen mehrere Ursachen infrage: ein nicht zurückgesetztes Tageskontingent, ein veralteter lokaler Zustand und eine Berechtigungsregel, die nicht an die Kontoidentität gekoppelt war. Ein Regelverstoß ließ sich nicht feststellen. Sowohl der Client als auch das Backend schienen einen Aktionszähler führen zu können. Der Fall warf eine Frage zur Konsistenz auf. Er belegte weder Fehlverhalten noch, wie hoch die Falsch-Positiv-Rate insgesamt ist.

Laut RFC 6585 (rfc-editor.org) signalisiert HTTP 429 eine Begrenzung der Anfragerate. Wie Nutzer identifiziert und Anfragen gezählt werden, legt der Standard nicht fest. Ein Statuscode allein erklärt nicht, ob ein Anspruch auf eine Prämie besteht.

Identität und Zählung brauchen getrennte Geltungsbereiche

Bei Aktionslimits für Lernangebote mit Prämien lautet die erste Gestaltungsfrage: Wem oder was ist das Kontingent zugeordnet?

• Ein Konto ist ein Datensatz für Anmeldung und Berechtigungen.
• Eine Person ist ein Mensch, aber nicht automatisch eine verifizierte Identität.
• Ein Gerät ist ein Zugangspunkt, den sich mehrere Personen teilen können.
• Eine Sitzung bildet einen abgegrenzten Rahmen für Interaktionen.
• Ein täglicher Aktionszähler bildet den Kontingentstand für einen bestimmten Geltungsbereich, eine Aktion und ein Zeitfenster ab.

Laut Androids Leitfaden zu Kennungen (developer.android.com) unterscheiden sich Kennungen in ihrem Geltungsbereich und ihrem Verhalten beim Zurücksetzen. Deshalb gehört die Unterscheidung zwischen Geräte-ID und Nutzeridentität ins Regelmodell, nicht nur in die Implementierungshinweise.

Zwei Zähler können widersprüchliche Antworten liefern

Ein Beispiel: Ein Aktionszähler in der App zählt bereits beim Antippen weiter, während das Backend nur akzeptierte Prämienanforderungen zählt. Nach einer Zeitüberschreitung bleibt offen, ob die Anfrage erfolgreich war. Ein erneuter Versuch, ein Kontowechsel oder ein veralteter Cache können dann unterschiedliche Zählerstände sichtbar machen.

Wie Androids Dokumentation zur Datensicherung (developer.android.com) erläutert, können gesicherte Einstellungen bei der Installation einer App wiederhergestellt werden. Eine Neuinstallation eignet sich daher nicht zuverlässig dazu, Berechtigungsprobleme zu untersuchen oder die Berechtigung zurückzusetzen.

Für jede Prämienanforderung muss derselbe Schnittstellenvertrag gelten

Gemäß OWASPs Empfehlungen für serverseitige Geschäftsregeln (cheatsheetseries.owasp.org) sollte für jede Aktion mit einem Limit genau eine verbindliche Entscheidung im Backend maßgeblich sein. Die Prüfung der Berechtigung und der Verbrauch des Kontingents sollten atomar erfolgen, damit parallele Anfragen nicht dasselbe Restkontingent verbrauchen können.

Die vorgeschlagene Antwortstruktur umfasst den Berechtigungsstatus, den Grund, den Geltungsbereich, das Restkontingent, den Rücksetzzeitpunkt, sofern bekannt, die Regelversion und die Entscheidungs-ID. Der Client zeigt dieses Ergebnis an, statt konkurrierende Regeln für den Prämienanspruch durchzusetzen. Ein Offline-Status bedeutet, dass die Berechtigung noch unbestätigt ist – nicht, dass das Kontingent aufgebraucht ist.

Wer nicht-idempotente Anfragen automatisch wiederholt, braucht laut den HTTP-Regeln für Wiederholungen (rfc-editor.org) eine Grundlage, um die Wiederholung als sicher einzustufen. Prämienanforderungen sollten einen dauerhaft gespeicherten Idempotenzschlüssel und das protokollierte Ergebnis wiederverwenden. So lassen sich doppelte Prämien und mehrfache Zählererhöhungen vermeiden.

Für geteilte Smartphones und Mitternacht braucht es klare Regeln

Die gemeinsame Nutzung eines Geräts sollte ein Risikosignal sein, kein automatischer Beleg für doppelt registrierte Lernende. Ist ein geräteweites Limit nötig, braucht es dafür eine ausdrückliche Begründung und die Möglichkeit einer Überprüfung. „Täglich“ muss sich auf einen festgelegten Tageswechsel oder ein rollierendes Zeitfenster beziehen. Dabei ist die Serverzeit maßgeblich.

• Zwei Konten nutzen dasselbe Smartphone, ohne das zwischengespeicherte Kontingent des jeweils anderen zu übernehmen.
• Ein Konto fordert gleichzeitig von zwei Geräten aus Prämien an.
• Erneute Verbindungen und Wiederholungsversuche nach einer Antwort mit unklarem Ergebnis.
• Neuinstallation und Wiederherstellung aus einer Datensicherung.
• Zeitzonenwechsel sowie Umstellungen zwischen Sommer- und Winterzeit rund um den Rücksetzzeitpunkt.

Support braucht nachvollziehbare Entscheidungen statt Rätselraten

Die Nachricht an Lernende sollte die tatsächliche Einschränkung und den Rücksetzzeitpunkt nennen, sofern das sicher möglich ist und die Angaben bekannt sind. Bei Sicherheitsprüfungen muss klar sein, wie eine Überprüfung möglich ist – ein erfundener Countdown hilft nicht. Der Support sollte datensparsame Entscheidungsprotokolle mit Entscheidungs-IDs, Änderungen der Zählerstände und Regelversionen erhalten. Verknüpfte Protokolle sind pseudonym, nicht anonym. Einsprüche und Ausnahmen sollten dokumentiert werden. Die Telemetrie sollte zwischen Missbrauchsverdacht, bestätigten Verstößen und aufgehobenen Einschränkungen unterscheiden.

Für App-Learning gehören die Schutzmechanismen gegen den Missbrauch von Lernprämien, die Nachrichten an Lernende und der Support in dasselbe System. Fairness bei LMS-Prämien heißt nicht, Regeln weniger konsequent durchzusetzen. Sie heißt, dass Geltungsbereich, Ergebnis und Korrekturweg durchgängig zusammenpassen – von der Entscheidung im Backend bis zum Bildschirm der Lernenden.