App-Berechtigungen erklären und sparsam anfordern

Eine App soll ein einzelnes Foto übernehmen. Trotzdem fragt sie beim ersten Start nach Standort, Kamera und Zugriff auf die gesamte Mediensammlung. Solche Anfragen entstehen häufig aus einer technischen Abkürzung: Die Entwicklung aktiviert vorsorglich alles, was später nützlich sein könnte. Für die Person am Bildschirm bleibt dagegen unklar, welche Aufgabe gerade welchen Zugriff verlangt. Ein besserer Entwurf beginnt deshalb vor dem Berechtigungsdialog. Er beschreibt die gewünschte Handlung und sucht den kleinsten passenden Zugang.

Dieser Leitfaden verbindet Produktentscheidungen mit einem vollständigen Webbeispiel: Eine Leseliste wird aus einer ausdrücklich ausgewählten JSON-Datei angezeigt. Die Anwendung benötigt dafür keinen Verzeichniszugriff. Das Beispiel ist keine Nachbildung eines Android- oder iOS-Systemdialogs. Es zeigt vielmehr, wie eine enger geschnittene Funktion einen breiteren Zugriff vermeiden kann. Technischer Quellenstand ist der 9. November 2026. Aussagen über konkrete Systemdialoge müssen zusätzlich an den tatsächlich unterstützten Plattformversionen überprüft werden.

Erst die Aufgabe beschreiben, dann den Zugriff wählen

Eine Berechtigungsanforderung ist noch keine Funktionsbeschreibung. „Wir brauchen Fotos“ erklärt weder, ob ein einzelnes Profilbild ausgewählt werden soll, noch, ob eine umfangreiche Bildverwaltung tatsächlich den ganzen Bestand durchsuchen muss. Schreiben Sie zunächst einen vollständigen Satz aus Sicht der verwendenden Person: „Ich möchte dieses Bild zu meinem Eintrag hinzufügen.“ Erst danach entscheiden Sie, welche Schnittstelle diese Handlung mit möglichst wenig zusätzlicher Reichweite ermöglicht.

Die kleinste sinnvolle Lösung ist dabei nicht zwangsläufig die Lösung mit dem kleinsten Dialog. Entscheidend sind Umfang, Zeitpunkt, Dauer und Verarbeitung. Ein unauffälliger Zugriff auf viele Daten kann weitreichender sein als eine deutlich erklärte einmalige Auswahl. Ebenso sagt ein bereits erteilter Zugriff nichts darüber aus, ob eine neue Funktion dieselben Informationen tatsächlich benötigt. Die Prüfung gehört deshalb zu jeder neuen Anforderung und nicht nur zur ersten Veröffentlichung.

Diese Tabelle ist eine Entwurfshilfe und keine universelle Austauschbarkeit von Schnittstellen. Ein manueller Ort kann eine Navigation nicht in jeder Situation ersetzen. Eine einzelne Bildauswahl genügt nicht für jede Bildverwaltung. Der Nutzen entsteht daraus, den breiteren Zugriff begründen zu müssen. Eine technische Bibliothek, die standardmäßig mehr anfordert, ersetzt diese Begründung nicht.

Vier Grenzen auseinanderhalten

Systemberechtigung, Dateiauswahl, Kontoberechtigung und datenschutzrechtliche Bewertung betreffen unterschiedliche Ebenen. Ein Betriebssystem kann den Mikrofonzugriff erlauben. Das bedeutet nicht, dass ein angemeldetes Konto jede Aufnahme einem fremden Projekt hinzufügen darf. Eine Person kann eine Datei auswählen. Daraus folgt nicht automatisch, dass die Anwendung deren Inhalt veröffentlichen oder an einen weiteren Dienst senden soll. Die Oberfläche muss die tatsächlich geplante Handlung erkennbar machen.

Dieser Beitrag behandelt technische und gestalterische Entscheidungen. Er setzt einen Systemklick nicht mit einer rechtlich wirksamen Einwilligung gleich und leitet daraus keine pauschale Rechtsgrundlage ab. Für eine reale Anwendung müssen Verantwortlichkeit, Zweck, Empfänger und einschlägige rechtliche Anforderungen eigenständig geprüft werden. Besonders wichtig wird diese Trennung, wenn zusätzliche Analysewerkzeuge, externe Verarbeitung oder gemeinsame Konten hinzukommen. Eine enge Betriebssystemfreigabe macht diese Fragen nicht überflüssig.

Dokumentieren Sie für jede Funktion eine kleine Zugriffskarte: auslösende Handlung, betroffene Daten, verwendete Schnittstelle, Reichweite, Verarbeitung und Alternative bei Ablehnung. Ergänzen Sie, wer Änderungen an dieser Karte freigibt. So lässt sich bei einer späteren Erweiterung erkennen, ob aus einem einzelnen Import schleichend eine dauerhafte Synchronisation geworden ist. Beide Funktionen können berechtigt sein. Sie benötigen aber unterschiedliche Erklärungen und Prüfungen.

Android und Apple verlangen eine eigene Plattformprüfung

Die Android-Dokumentation zu Laufzeitberechtigungen beschreibt kontextbezogene Anfragen und einen sinnvollen Umgang mit Ablehnung. Eine bereits früher erteilte Berechtigung sollte nicht als dauerhaft unveränderlicher Zustand behandelt werden. Prüfen Sie die notwendige Berechtigung erneut vor der geschützten Operation. Die fachliche Funktion muss erklären können, welche Handlung bei fehlendem Zugriff ausbleibt und welche anderen Teile weiter nutzbar bleiben.

Bei Bildern lohnt sich außerdem der Blick auf den Android Photo Picker. Er ermöglicht eine ausdrücklich begrenzte Medienauswahl statt eines pauschalen Zugangs zum gesamten Bestand. Ob diese Schnittstelle die Produktanforderung erfüllt, hängt vom tatsächlichen Ablauf und der unterstützten Umgebung ab. Der hier gezeigte Browsercode ist keine Implementierung dieses Android-Werkzeugs. Native Einbindung, Rückgabewerte und Wiederverwendung ausgewählter Inhalte benötigen eigene Prüfungen.

Apples Gestaltungsrichtlinien zu Privatsphäre betonen einen nachvollziehbaren Bedarf und konkrete Zweckbeschreibungen. Vermeiden Sie dabei den Fehler, eine eigene Vorabansicht wie einen bereits zustimmenden Systemdialog aussehen zu lassen. Die Plattform macht für solche Ansichten besondere Vorgaben. Übernehmen Sie deshalb keine vermeintlich plattformübergreifende Dialogschablone. Ein fachlicher Einstieg mit optionaler Funktion und der genaue Ablauf vor einem Systemdialog sind getrennt zu gestalten.

Führen Sie für native Apps eine Testmatrix mit Geräteversion, bisherigem Berechtigungszustand und aufgerufener Funktion. Ein frisches Gerät allein genügt nicht. Prüfen Sie auch eine nachträgliche Änderung in den Systemeinstellungen sowie das erneute Aufrufen einer Funktion. Ob und wie ein Dialog nochmals erscheint, darf nicht aus einem beliebigen Entwicklungslauf verallgemeinert werden. Hintergrundzugriffe benötigen eine eigene Betrachtung und dürfen nicht stillschweigend aus einer Freigabe für einen anderen Nutzungskontext abgeleitet werden.

Ein begrenzter Import statt eines breiten Dateizugriffs

Unser Beispiel hat einen bewusst kleinen Auftrag: Eine Person wählt eine JSON-Leseliste mit höchstens 20 Titeln. Die Ansicht zeigt diese Titel an. Sie verändert die Quelldatei nicht, überträgt ihren Inhalt nicht und speichert die Auswahl nicht dauerhaft. Das sind Eigenschaften dieses konkreten Codes. Ein Dateiauswahldialog allein garantiert keineswegs, dass eine andere Anwendung ausgewählte Inhalte nicht anschließend versendet. Prüfen Sie immer den gesamten nachfolgenden Datenweg.

Das Dateifeld besitzt weder das Attribut für mehrere Dateien noch eine Verzeichnisauswahl. Der Hinweis accept erleichtert lediglich die Auswahl passender Dateien. Die Dokumentation zum HTML-Dateifeld macht deutlich, dass dieser Hinweis keine Inhaltsvalidierung ersetzt. Unser Prüflauf wählt deshalb absichtlich eine Textdatei mit gültigem JSON-Inhalt aus. Sie kann erfolgreich gelesen werden. Dateiendung und gemeldeter Medientyp entscheiden hier nicht über die fachliche Gültigkeit.

Das Format besitzt genau die Eigenschaften version und items. Version eins enthält eine Liste aus Objekten mit jeweils genau einem Titel. Zusätzliche Eigenschaften werden abgelehnt. Die Größenbegrenzung von 32 KiB ist eine eigene Produktentscheidung für dieses kleine Beispiel und kein allgemeines Plattformlimit. Ebenso sind die Obergrenze von 20 Einträgen und die Titellänge von 200 JavaScript-Codeeinheiten bewusst gewählte Grenzen. Sichtbare Zeichen können aus mehreren solchen Einheiten bestehen.

{"version":1,"items":[{"title":"Farben im Interface"},{"title":"Verständliche Formulare"}]}

Der vollständige Lesekern

Die erste Prüfung findet vor dem Lesen statt. Anschließend wird die Größe des gelesenen Textes nochmals als UTF-8 geprüft. Das verhindert im Beispiel auch, dass ein eingesetztes Testobjekt eine falsche Größenangabe liefert. Echte Browserdateien und absichtlich eingesetzte Prüfobjekte sind dabei unterschiedliche Dinge. Die zweite Grenze macht aus der Funktion weder einen allgemeinen Dateiscanner noch einen Schutz gegen sämtliche denkbaren Ressourcenangriffe. Der Auftrag bleibt das begrenzte Lesen dieses Formats.

export const MAX_BYTES = 32768;
export async function readList(file) {
  if (!file || !Number.isSafeInteger(file.size) || file.size < 0 || file.size > MAX_BYTES || typeof file.text !== 'function') {
    throw new TypeError('Datei darf höchstens 32 KiB groß sein.');
  }
  const text = await file.text();
  if (typeof text !== 'string' || new TextEncoder().encode(text).length > MAX_BYTES) throw new TypeError('Datei ist zu groß.');
  let data;
  try { data = JSON.parse(text); } catch { throw new TypeError('Datei enthält kein gültiges JSON.'); }
  if (!data || Array.isArray(data) || Object.keys(data).sort().join(',') !== 'items,version' || data.version !== 1 ||
      !Array.isArray(data.items) || data.items.length < 1 || data.items.length > 20) throw new TypeError('Format der Leseliste ist ungültig.');
  const items = data.items.map(item => {
    if (!item || Array.isArray(item) || typeof item !== 'object' || Object.keys(item).join(',') !== 'title' ||
        typeof item.title !== 'string' || item.title.trim().length < 1 || item.title.trim().length > 200) {
      throw new TypeError('Ein Titel ist ungültig.');
    }
    return {title: item.title.trim()};
  });
  return items;
}

text() liefert ein asynchrones Ergebnis. Die Dokumentation zur Textmethode beschreibt die Interpretation als UTF-8. Unser Format setzt diese Kodierung voraus. Für andere Austauschformate müsste die Anwendung deren Kodierung ausdrücklich behandeln. Auch doppelt vorkommende JSON-Schlüssel werden hier nicht durch einen eigenen Parser zurückgewiesen: Die Verarbeitung folgt dem Verhalten von JSON.parse. Ein System mit einer Anforderung an eindeutige Rohschlüssel bräuchte eine zusätzliche passende Prüfung.

Die Funktion erzeugt neue Ergebnisobjekte mit gekürzten äußeren Leerzeichen. Sie gibt weder die vollständige Eingabe noch unbekannte Felder weiter. Ein lesbarer Titel bleibt trotzdem fremder Inhalt. Erst die Ausgabe entscheidet, ob dieser Inhalt als Text oder als ausführbares Markup behandelt wird. Deshalb gehört die zweite Hälfte des Beispiels ebenso zur Sicherheitsbetrachtung wie die Formatprüfung. Eine korrekte Datenstruktur ersetzt keine korrekte Ausgabe.

Die vollständige Ansicht und ihre Zustände

Die beiden folgenden Dateien gehören in dasselbe Verzeichnis und werden über einen Entwicklungsserver aufgerufen. Die Ansicht benutzt ein sichtbares natives Dateifeld mit zugeordnetem Label. Ein Hilfetext nennt Format und Grenzen. Der Status beschreibt das tatsächliche Ergebnis. Die Schaltfläche zum Entfernen spricht ausdrücklich nur von dieser Ansicht. Sie behauptet weder, die Quelldatei zu löschen, noch eine umfassendere Betriebssystemberechtigung zu widerrufen.

<!doctype html><html lang="de"><meta charset="utf-8"><title>Leseliste aus einer Datei ansehen</title><meta name="viewport" content="width=device-width,initial-scale=1">
<style>body{font:20px/1.5 system-ui;max-width:48rem;margin:2rem;background:#fff6e8;color:#29252a}input,button{font:inherit;padding:.7rem}button{margin-top:1rem}*:focus-visible{outline:3px solid #bd1741;outline-offset:3px}label{font-weight:bold;display:block}li{margin:.6rem 0}#status{min-height:3rem}</style>
<h1>Leseliste aus einer Datei ansehen</h1><p>Wählen Sie eine JSON-Leseliste aus. Ihr Inhalt wird in dieser Ansicht angezeigt. Die Datei wird nicht versendet oder verändert.</p>
<label for="source">Eine Leseliste auswählen</label><p id="help">Eine JSON-Datei, höchstens 32 KiB, mit einem bis 20 Titeln.</p><input id="source" type="file" accept=".json,application/json" aria-describedby="help">
<p id="status" role="status">Noch keine Datei ausgewählt.</p><h2>Ausgewählte Titel</h2><ul id="items"></ul><button id="clear" type="button">Auswahl aus dieser Ansicht entfernen</button>
<script type="module">
import {readList} from './read-list.mjs';
const input=document.querySelector('#source'),status=document.querySelector('#status'),list=document.querySelector('#items');let generation=0;
function show(items){list.replaceChildren(...items.map(item=>{const li=document.createElement('li');li.textContent=item.title;return li;}));}
input.addEventListener('change',async()=>{
 const current=++generation,file=input.files?.[0];show([]);
 if(!file){status.textContent='Keine Datei ausgewählt.';return;}
 status.textContent='Leseliste wird gelesen.';
 try{const items=await readList(file);if(current!==generation)return;show(items);status.textContent=items.length+' Titel aus der ausgewählten Datei angezeigt.';}
 catch{if(current!==generation)return;show([]);status.textContent='Diese Datei konnte nicht als Leseliste gelesen werden. Prüfen Sie Format und Größe.';}
});
input.addEventListener('cancel',()=>{status.textContent=list.children.length?'Keine neue Auswahl. Die bisherige Ansicht bleibt erhalten.':'Keine Datei ausgewählt.';});
document.querySelector('#clear').addEventListener('click',()=>{generation++;input.value='';show([]);status.textContent='Auswahl aus dieser Ansicht entfernt. Die ursprüngliche Datei bleibt erhalten.';});
</script></html>

Die Anzeige verwendet textContent. Ein Titel wie ein HTML-Bildelement erscheint daher als sichtbarer Text. Er erzeugt kein Bildelement. Bei einer fehlerhaften neuen Datei werden frühere Titel zunächst entfernt, damit nicht eine alte erfolgreiche Auswahl versehentlich wie das neue Ergebnis aussieht. Ein abgebrochener erneuter Auswahldialog lässt dagegen die bereits angezeigte Liste bestehen. Die Statusmeldung benennt diesen Unterschied statt beides als Erfolg zu melden.

Die Variable generation löst eine weitere praktische Schwierigkeit. Während eine Datei gelesen wird, kann die Person die Auswahl entfernen oder eine neue Datei wählen. Eine später eintreffende alte Antwort darf diese neue Entscheidung nicht überschreiben. Jede neue Auswahl und jedes Entfernen ändern deshalb die Kennung. Nur ein Ergebnis mit der aktuellen Kennung darf die Ansicht aktualisieren. Ein Abbruch der erneuten Auswahl beendet keinen bereits laufenden früheren Lesevorgang. Er trifft lediglich keine neue Auswahl.

Was die 51 Prüfungen wirklich belegen

Der eigene Prüflauf umfasst 51 erfolgreiche Bedingungen. Im Funktionskern werden unter anderem gültige Einzel- und Mehrfacheinträge, die exakte Größengrenze, fehlende Felder, zusätzliche Eigenschaften und ungültige Titel geprüft. Ein absichtlich ausgelöster Lesefehler muss weitergegeben werden. Die Zahlen beschreiben diesen konkreten Nachweis und sind keine allgemeine Sicherheitsbewertung. Eine größere Zahl von Bedingungen würde nicht automatisch eine größere fachliche Abdeckung bedeuten.

Die Browserprüfung lief in Edge mit synthetischen Dateien, die das Prüfwerkzeug an das Dateifeld übergibt. Der tatsächliche Browser verarbeitet dabei Dateiobjekte und aktualisiert die Oberfläche. Der Systemauswahldialog wurde nicht bedient. Das Abbruchereignis und eine verzögerte Leseantwort wurden gezielt eingespeist. Diese Abgrenzung ist wesentlich: Der Nachweis zeigt Verhalten der implementierten Ansicht, aber keine getesteten Android- oder iOS-Freigaben und keine gesprochenen Ausgaben eines Bildschirmleseprogramms.

Während dieses Ablaufs wurde außerdem beobachtet, dass keine POST-Anfrage und kein Aufruf eines fremden Ursprungs stattfinden. Der geprüfte Ablauf hinterlässt keine Einträge in den beiden Webspeichern localStorage und sessionStorage. Das ist keine Aussage über Browsercache, Betriebssystemprotokolle oder andere Anwendungen. Es begründet die engere Aussage zum Beispiel: Der implementierte Import versendet keinen Dateiinhalt und legt die Leseliste nicht in diesen Speichern ab.

Ablehnung als normalen Produktzustand gestalten

Übertragen Sie diesen Ansatz auf Funktionen mit echten Systemberechtigungen. Eine Ablehnung darf nicht als ungewöhnlicher Defekt behandelt werden. Die Oberfläche sollte erklären, welche gerade gewählte Funktion deshalb nicht ausgeführt wurde. Vermeiden Sie wiederkehrende Aufforderungen bei jedem Wechsel der Ansicht. Eine erneute Erklärung ist dann sinnvoll, wenn die Person die betroffene Funktion bewusst erneut aufruft und die Plattform dafür einen passenden Weg vorsieht. Der genaue Systemzustand entscheidet über diesen Weg.

Trennen Sie dabei „nicht angefragt“, „abgelehnt“, „aktuell verfügbar“ und „nicht mehr verfügbar“. Ergänzen Sie fachliche Zwischenzustände wie laufende Aufnahme oder teilweise importierter Bestand, wenn das Produkt sie tatsächlich hat. Eine Funktion kann mit weniger Daten nützlich bleiben. Sie darf aber nicht behaupten, eine Aufnahme, Standortbestimmung oder Erinnerung erfolgreich eingerichtet zu haben, wenn dafür eine notwendige Voraussetzung fehlt. Ehrliche Zustände sind hilfreicher als ein grünes Symbol ohne ausgeführte Handlung.

Checkliste für die nächste Freigabe

Eine Abnahme braucht außerdem ein gemeinsames Verständnis der gespeicherten Zustände. Wenn ein Konto sich die letzte erfolgreiche Auswahl merkt, muss geklärt werden, was davon tatsächlich erhalten bleibt. Ein Dateiname ist nicht der Dateiinhalt. Eine interne Datensatznummer ist nicht automatisch ein erneuerbarer Dateizugriff. Ein Vorschaubild kann selbst bereits personenbezogene Informationen enthalten. Schreiben Sie deshalb nicht pauschal „Auswahl gespeichert“, wenn die Implementierung nur einen Titel oder eine Referenz aufbewahrt. Benennen Sie die fachlich relevante Wirkung.

Für das Leselistenbeispiel ergibt sich eine einfache Grenze: Nach dem Entfernen enthält die Ansicht keine Titel und das Dateifeld keine Auswahl. Die ursprüngliche Datei bleibt an ihrem bisherigen Ort. Ein Neuladen der Ansicht startet ebenfalls ohne Leseliste. Die Funktion hat keinen Serverzustand, den sie zusätzlich bereinigen müsste. Sobald eine spätere Version Listen einem Konto zuordnet, reicht diese Beschreibung nicht mehr aus. Dann müssen Anzeige, gespeicherte Kopie, Sicherung und gegebenenfalls externe Verarbeitung gesondert betrachtet werden.

Auch die Fehlerkommunikation verdient eine eigene Entscheidung. Der Funktionskern unterscheidet mehrere Formatfehler. Die Oberfläche fasst sie hier in einer verständlichen Meldung zusammen. Das hält das kleine Beispiel übersichtlich. Ein produktiver Import kann gezieltere Hinweise brauchen, etwa zur erwarteten Versionsnummer oder zur Zahl der Einträge. Dabei sollte die Meldung weder Dateiinhalte ungefragt vollständig anzeigen noch technische Ausnahmen als verständliche Anleitung ausgeben. Prüfen Sie, welche Information der betroffenen Person tatsächlich beim nächsten Versuch hilft.

Planen Sie für eine solche Erweiterung eine Fehlertabelle mit Ursache, sichtbarer Nachricht, nächster möglicher Handlung und verbleibenden Daten. Bei einer beschädigten JSON-Datei ist eine erneute Dateiauswahl sinnvoll. Bei einer zu großen Liste kann ein vorgeschalteter Export mit weniger Einträgen helfen. Bei einer zwischenzeitlich entfernten Systemberechtigung kann eine native Funktion einen anderen Weg benötigen. Diese Fälle teilen eine ausbleibende Verarbeitung, aber nicht zwangsläufig denselben hilfreichen nächsten Schritt.

Prüfen Sie außerdem die Bedienung ohne Zeigegerät. Im automatischen Browserlauf erreicht die Tastatur das sichtbare Dateifeld. Das allein beweist noch nicht, dass die gesamte Auswahl mit jeder Kombination aus Betriebssystem und Hilfstechnik verständlich bedienbar ist. Eine manuelle Abnahme sollte den echten Dialog, die Rückkehr in die Ansicht und die Statusrückmeldung einschließen. Vergrößerte Schrift, kleine Bildschirmbreiten und übersetzte Zwecktexte gehören ebenfalls in diese Prüfung. Eine korrekte Zugriffsgrenze kann durch eine unverständliche Bedienung praktisch wirkungslos werden.

Verantwortung lässt sich schließlich nicht vollständig an einen Berechtigungsmanager delegieren. Eine gemeinsame technische Komponente kann Zustände vereinheitlichen und doppelte Anfragen vermeiden. Die jeweilige Fachfunktion muss trotzdem bestimmen, warum sie Zugriff benötigt, welche Alternative funktioniert und wann sie ihre Arbeit tatsächlich beendet hat. Ein zentrales Modul kennt diese fachlichen Unterschiede nicht automatisch. Hinterlegen Sie die Zugriffskarte deshalb bei der Funktion und verbinden Sie Änderungen daran mit einer konkreten Abnahme. So bleibt die Erklärung auch dann überprüfbar, wenn mehrere Teams dieselbe technische Bibliothek nutzen.

• Ist die gewünschte Handlung als konkreter Satz beschrieben?
• Wurde ein enger Auswahlweg vor einem breiten Zugriff geprüft?
• Erklärt die Oberfläche Zweck und tatsächlichen Datenweg verständlich?
• Sind Systemzugriff, Kontorechte und rechtliche Bewertung getrennt dokumentiert?
• Wird nur die gerade benötigte Funktion angefragt?
• Bleiben Ablehnung und späterer Widerruf bedienbare Zustände?
• Werden ausgewählte Inhalte unabhängig von Dateiendungen geprüft?
• Können alte asynchrone Antworten keine neue Entscheidung überschreiben?
• Benennen Entfernen, Speichern und Versenden jeweils ihre tatsächliche Wirkung?
• Enthält die Abnahme neben automatischen Prüfungen die relevanten echten Geräteabläufe?

Bewahren Sie zu jeder Freigabe die geprüfte Fassung, die verwendeten Plattformstände und die beobachteten Grenzen auf. Prüfen Sie erneut, wenn eine Bibliothek den Auswahldialog ersetzt, ein Import künftig an einen Server geht oder ein weiterer Verwendungszweck hinzukommt. Die ursprüngliche Erklärung kann dann fachlich falsch werden, obwohl das Dateifeld gleich aussieht. Sparsame Berechtigungen sind deshalb keine einmalige Formulierung. Sie entstehen aus einer überschaubaren Aufgabe, einer passenden Schnittstelle und einem überprüfbaren Datenweg.