Was kann ein Absturzbericht einer Tagebuch-App enthalten?
Ein Absturzbericht einer Tagebuch-App kann technische Details wie den Stack-Trace des Absturzes, Geräte- und App-Versionen, Zeitstempel und zeitnahe Diagnoseereignisse enthalten. Abhängig vom Betriebssystem, dem Berichterstattungsdienst und der App-Konfiguration kann er auch Protokolle, Anhänge oder Session-Replay-Daten umfassen, die in der App eingegebene oder angezeigte Inhalte offenlegen. Ein Bericht enthält nicht in jedem Fall automatisch Tagebucheinträge, und es ist nicht sicher davon auszugehen, dass er dies niemals tut. Prüfen Sie den spezifischen Bericht und die Konfiguration der App, bevor Sie ihn weitergeben.
Was zeigt ein standardmäßiger Absturzbericht?
Ein Stack-Trace listet Funktionsaufrufe auf, die mit dem Absturz verknüpft sind. Er hilft Entwicklern, den betroffenen Codepfad zu lokalisieren, erklärt für sich genommen jedoch meist nicht die vollständigen Umstände und belegt nicht, was der Benutzer gerade getan hat. Berichte können auch die App- und Betriebssystemversionen, das Gerätemodell, den Absturzzeitpunkt und weitere Umgebungsdetails angeben. Apple beschreibt Absturzberichte als Aufzeichnungen des App-Status zum Zeitpunkt eines Absturzes und empfiehlt die Analyse des vollständigen Betriebssystemberichts; dessen Leitfaden führt Felder wie Geräte-, App- und OS-Informationen auf. Siehe Apples [Leitfaden zur Analyse von Absturzberichten](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report).
Das Berichtsformat hängt von seiner Quelle ab. Über Xcode erfasste Apple-Absturzberichte und ein Android-Fehlerbericht sind unterschiedliche Artefakte. Der offizielle Android-Leitfaden besagt, dass ein Bug-Report Geräteprotokolle, Stack-Traces, Diagnoseausgaben von Systemdiensten, Fehlerprotokolle und Systemnachrichten von Apps enthalten kann, die Androids `Log`-Klasse verwenden. Das geht über einen reinen Absturzdatensatz hinaus. Der Inhalt eines einzelnen Berichts hängt dennoch davon ab, was erfasst und einbezogen wurde. Siehe [Androids Anleitung zum Erfassen und Lesen von Fehlerberichten](https://developer.android.com/studio/debug/bug-report).
Kann der Bericht Tagebuchtexte enthalten?
Unter bestimmten Konfigurationen ist dies möglich, aber das bloße Vorhandensein eines Absturzberichts belegt nicht zwingend, dass er Eintragstexte enthält. Die entscheidende Frage ist, was die App parallel zum Absturz aufzeichnet und was das Berichtsformat erfasst.
Beispielsweise können App-Entwickler Diagnoseprotokollmeldungen oder benutzerdefinierte Ereignisse hinzufügen. Wenn diese Meldungen einen Tagebucheintrag, einen Titel, einen Suchbegriff oder aus einem Editor kopierten Text enthalten, könnten diese Informationen mit dem Ereignis übertragen werden. Sentry beschreibt Breadcrumbs als eine Spur von Ereignissen vor einem Problem; jedes kann eine Nachricht und beliebige strukturierte Daten enthalten. Breadcrumbs können automatisch über aktivierte Integrationen gesammelt oder von einer App hinzugefügt werden. Siehe [Sentrys Dokumentation zu Breadcrumbs](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Android-Fehlerberichte enthalten zudem Systemnachrichtenprotokolle, die von Apps geschriebene Nachrichten enthalten können. Keine dieser Tatsachen bedeutet, dass jede App private Texte protokolliert: Dies hängt von der Implementierung und Konfiguration der App ab.
Was sind Logs, Breadcrumbs, Anhänge und Replays?
Diese Begriffe bezeichnen unterschiedliche Arten von Diagnosedaten. Protokolle (Logs) sind von der App oder dem System aufgezeichnete Meldungen. Breadcrumbs sind eine ausgewählte Abfolge von Ereignissen, die zu einem Fehler führten, und können Zeitstempel, Kategorien, Meldungen sowie Schlüssel-Wert-Daten enthalten. Beide können je nachdem, was die App aufzeichnet, mehr Kontext offenbaren als ein Stack-Trace.
Anhänge sind Dateien, die mit einem Ereignis gesendet werden, wie etwa eine Protokolldatei, ein Screenshot oder ein Crash-Dump. Sentry weist darauf hin, dass native Minidumps sensible Daten wie Umgebungsvariablen, lokale Pfade oder Abbilder von Eingabefeldern im Arbeitsspeicher enthalten können. Laut Dokumentation werden Minidumps verwendet, um Ereignisse zu erstellen, und standardmäßig verworfen; sie können jedoch als Anhänge gespeichert werden, wenn diese Einstellung aktiviert ist. Zudem wird darauf hingewiesen, dass Anhänge nicht von Sentrys Datenbereinigung (Data Scrubbing) abgedeckt werden. Siehe Sentrys Dokumentation zu [Absturzdaten](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) und [Anhängen](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
Session Replay ist eine separate, optionale Funktion und kein Standardbestandteil jedes Absturzberichts. Sentrys JavaScript-Replay-Dokumentation beschreibt eine videoähnliche Rekonstruktion von Browseraktivitäten, einschließlich DOM-Status und Interaktionen. Laut Dokumentation maskiert das SDK standardmäßig DOM-Texte, Bilder und Benutzereingaben, bietet jedoch auch Konfigurationsoptionen. Maskierungseinstellungen und unterstützte Plattformen spielen eine Rolle: Gehen Sie nicht davon aus, dass Tagebuchinhalte sichtbar oder geschützt sind, ohne die tatsächliche Einrichtung des Anbieters und die Datenschutzeinstellungen überprüft zu haben. Siehe [Sentrys Leitfaden zu JavaScript Session Replay](https://docs.sentry.io/platforms/javascript/session-replay/).
Was sollten Sie überprüfen, bevor Sie einen Bericht teilen?
Wenden Sie diese Checkliste auf die eigentliche Datei oder die Berichtsvorschau an und prüfen Sie die Datenschutzdokumentation der App oder des Anbieters, wenn der Inhalt des Berichts unklar ist:
Diese Checkliste ist ein praktischer redaktioneller Leitfaden für Tagebuchnutzer, die einen Bericht vor dem Versenden überprüfen. Sie unterscheidet sich von Herstelleranweisungen: Entwickler steuern ihre eigenen Logging-, Replay- und Anhang-Einstellungen und sollten dokumentieren, was diese Funktionen erfassen, sowie prüfen, ob Diagnosefelder benutzereingegebene Inhalte enthalten können.
Warum können sich Berichte zwischen Apps und Geräten unterscheiden?
Betriebssysteme erzeugen unterschiedliche Berichtsformate und Erfassungswege; Entwickler können zudem ein Drittanbieter-SDK mit benutzerdefinierter Konfiguration verwenden. Apple gibt an, dass App-Store- und TestFlight-Absturzberichte über Xcode verfügbar sind, während andere Diagnoseprotokolle möglicherweise von einem Gerät übertragen werden müssen. Android unterscheidet vollständige Bug-Reports von Absturzberichten, die über Dienste wie Google Play oder Firebase bereitgestellt werden. Anbietereinstellungen können des Weiteren bestimmen, welche Ereignisse, Breadcrumbs, Anhänge oder Replay-Daten erfasst und gespeichert werden. Betrachten Sie die Datenschutzerklärung der App und den tatsächlichen Bericht als Orientierung für den jeweiligen Einzelfall, anstatt anzunehmen, dass jeder Dienst dieselben Felder übermittelt.