# Datenschutzgrundlage für barrierex Recherche- und Abrufstand: **29. Oktober 2026**. Ausschließlich amtliche Rechtsquellen und Dokumentation der zuständigen Plattformen. Diese Datei dokumentiert Anforderungen und technische Empfehlungen; sie ist keine rechtliche Freigabe einer konkreten Veröffentlichung und keine Aussage, dass sämtliche Maßnahmen bereits implementiert sind. Betreiber, Hosting, Verträge und die endgültige Implementierung müssen zusammenpassen. ## 1. Was „datenschutzfreundlich“ hier konkret heißen sollte Das Produkt besteht aus unterschiedlichen Datenflüssen: öffentlicher Landingpage, eingebettetem Website-Widget, optionalem lokalem Dashboard/Scanner und Browsererweiterung. Eine Aussage für einen Bereich gilt nicht automatisch für die anderen. „Keine Analyse-Tracker“ ist eine überprüfbare Eigenschaft; „verarbeitet keine Daten“ wäre falsch, sobald eine Website ausgeliefert, eine Seite geprüft oder ein Bericht erzeugt wird. Die DSGVO fordert unter anderem einen festgelegten Zweck und eine Rechtsgrundlage, Datenminimierung, Speicherbegrenzung, angemessene Sicherheit und nachweisbare Verantwortlichkeit. Art. 13 verlangt bei Erhebung insbesondere Informationen zu Verantwortlichem, Zweck/Rechtsgrundlage, Empfängern, Speicherzeit/-kriterien, Betroffenenrechten und gegebenenfalls Drittlandübermittlung. Die konkrete Rechtsgrundlage ist pro Verarbeitung festzulegen; sie folgt nicht allein daraus, dass Software kostenlos ist. [DSGVO, insbesondere Art. 5, 6, 13 und 32](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679) Art. 25 betrifft die Gestaltung und Voreinstellungen: Nur erforderliche personenbezogene Daten sollen standardmäßig verarbeitet werden. Für dieses Produkt folgt daraus als eigene technische Ableitung: keine Marketing-SDKs, keine remote eingebetteten Schriftarten oder Tutorials, lokale Prüfung in der Erweiterung, keine Hintergrundübermittlung von Seiteninhalten und möglichst kurze, dokumentierte Aufbewahrung. [Amtlicher Text, Art. 25](https://eur-lex.europa.eu/legal-content/eng/TXT/PDF/?uri=CELEX%3A32016R0679) ## 2. Widget: Speicherzugriff und Vorlesen ### LocalStorage ist nicht vom TDDDG ausgenommen § 25 TDDDG erfasst sowohl das Speichern als auch den Zugriff auf Informationen im Endgerät. Die Norm ist nicht auf Cookies oder personenbezogene Daten beschränkt. Grundsätzlich ist eine informierte Einwilligung vorgesehen; eine Ausnahme besteht unter anderem für unbedingt erforderliche Vorgänge zur Bereitstellung eines ausdrücklich gewünschten digitalen Dienstes. Die Ausnahme ist keine allgemeine Erlaubnis für Komfort-, Werbe- oder Analysefunktionen. [§ 25 TDDDG](https://www.gesetze-im-internet.de/ttdsg/__25.html) **Eigene Umsetzungsempfehlung:** Standardmäßig nur Arbeitsspeicher verwenden. Einstellungen verändern die aktuelle Seite, ohne dass beim ersten Seitenaufruf eine Kennung oder Präferenz gespeichert wird. Eine zusätzliche, nicht vorausgewählte Funktion „Einstellungen auf diesem Gerät merken“ erklärt Zweck und Dauer direkt am Schalter. Sie benötigt eine echte Abschalt-/Löschmöglichkeit. Ob eine konkrete persistente Einstellung als ausdrücklich gewünschte Funktion unter die gesetzliche Ausnahme fällt, muss anhand der tatsächlich gebotenen Funktion bewertet werden. Keine pauschale Werbeaussage „cookie-frei, deshalb immer ohne Einwilligung“. **Befund des zu Beginn dieser Recherche gelesenen Codes:** `public/barrierex-widget.js` liest `barrierex-assist` aus LocalStorage schon bei der Initialisierung. `apply()` schreibt ebenfalls sofort. Das erfüllt noch keine Voreinstellung „kein Speicherzugriff vor Interaktion“. Der Reset sollte gespeicherte Einstellungen entfernen und nicht lediglich ein neues Default-Objekt zurückschreiben. ### Vorlesen kann einen entfernten Dienst nutzen Die Web Speech API unterscheidet lokale und entfernte Stimmen über `SpeechSynthesisVoice.localService`. Eine Browser-Vorlesefunktion ist daher nicht automatisch ein rein lokaler Dienst. [Mozilla: localService](https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesisVoice/localService) **Eigene Umsetzungsempfehlung:** Ausschließlich eine passende Stimme mit `localService === true` auswählen. Ist noch keine Stimme geladen, `voiceschanged` berücksichtigen. Ist keine geeignete lokale Stimme verfügbar, diese Situation sichtbar erklären und nicht still auf eine entfernte Stimme zurückfallen. Nur die ausdrücklich markierte Auswahl vorlesen; weder gesamten Seiteninhalt noch Formulare automatisch einsammeln. Die Auswahl nicht speichern oder protokollieren. „Von deinem Browser als lokal ausgewiesene Stimme“ ist präziser als eine Garantie über sämtliche Betriebssystemdienste. ### Einbindung und Netzverkehr Bei einem fremd gehosteten Script erfolgt bereits zum Laden eine Verbindung zum Script-Host. Ein selbst gehostetes Script vermeidet diesen zusätzlichen Empfänger. `referrerpolicy="no-referrer"` reduziert den Referrer beim Abruf, ersetzt aber keine Erklärung des Datenflusses. Der Widget-Code sollte keine Telemetrie, keinen Lizenz-Ping und keine unsichtbaren Requests enthalten. Eine statische Datei auf der Kundendomain ist der bevorzugte Integrationsweg. Dieser Abschnitt ist eine technische Bewertung der eigenen Architektur, keine pauschale rechtliche Einordnung aller Hoster. ## 3. Landingpage und Videos Eigene Fonts, SVGs, Videos, Posterbilder, Untertitel und Transkripte unter derselben Origin ausliefern. Kein automatisches YouTube-/Vimeo-/Loom-iframe und keine eingebetteten Social-Media-Buttons. Gewöhnliche externe Links sind von automatisch geladenen Drittanbieter-Embeds zu unterscheiden. `preload="none"` oder `metadata` vermeidet unnötige Videotransfers; Abspielen erfolgt nach Klick. Ein Cookie-Banner ist kein Selbstzweck. Ob eine Einwilligung nötig ist, ergibt sich aus den tatsächlichen Endgerätezugriffen und Verarbeitungen. Ein Banner darf insbesondere keine behaupteten Marketing-Kategorien enthalten, die es gar nicht gibt. Eine technisch schlichte Seite ohne zusätzliche Speicher-/Trackingfunktionen kann ohne Marketing-CMP gebaut werden; ihre Hostingverarbeitung bleibt in den Datenschutzhinweisen zu erläutern. Anleitungsvideos dürfen keine echten Zugangsdaten, Kundendaten oder fremden Accounts zeigen. Nachgestellte Oberflächen sind als „animierte Anleitung“ oder „schematische Klickanleitung“ zu kennzeichnen. Sie dürfen nicht als Aufnahme einer tatsächlich ausgeführten Fremdplattform-Installation erscheinen. Menübezeichnungen, Produktvarianten und etwaige Tarifgrenzen müssen auf aktuelle Herstellerquellen zurückgehen. ## 4. Dashboard, Scanner und Serverlogs ### Datenbestand Im zu Beginn gelesenen Projekt werden Website-URLs, HTML-Fundstellen, Selektoren, Zuständigkeiten, Notizen, Kontakte, Scan-Snapshots und manuelle Testergebnisse in SQLite gehalten. Solche Felder können personenbezogene Daten enthalten. Öffentlich zugängliche Inhalte werden dadurch nicht automatisch unpersönlich. Roh-HTML, `value`-Attribute, URL-Abfragen und Freitext sollten nur gespeichert werden, soweit sie für die Diagnose benötigt werden. „Reduziert“ oder „bereinigt“ darf nicht mit „anonymisiert“ gleichgesetzt werden. **Eigene technische Maßnahmen:** - API-Antworten und Exporte mit `Cache-Control: no-store` ausliefern. - Zugriff auf produktive Workspaces authentifizieren; Loopback allein ist nur für den lokalen Einzelbetrieb gedacht. - TLS am produktiven Reverse Proxy; Schlüssel nicht in URLs oder Frontend-Builds einbetten. - Request-Logging im Fastify-Standard deaktivieren. Fehlerlogs ohne vollständige URLs, Body, Authorization, Cookies oder IP-Adressen strukturieren. - Eine Konfiguration der Logaufbewahrung für Reverse Proxy und Hoster separat dokumentieren. Die Node-App kann deren Logs nicht abschalten. - Optionales Befund-HTML vor Speicherung begrenzen und typische Formularwerte entfernen. Das ist Datensparsamkeit, kein verlässlicher personenbezogener-Daten-Detektor. - Scan-Aufbewahrung konfigurierbar machen. Alte Snapshots, zugehörige Fundstellen und verwaiste Records konsistent behandeln. Eine gewählte Defaultfrist ist eine Produktentscheidung, keine gesetzlich universell vorgeschriebene Anzahl Tage. - Export und gezieltes Löschen in der Oberfläche anbieten; Löschung laufender Scan-Daten mit Queue-Zustand koordinieren. - Backup/WAL-Aufbewahrung gesondert berücksichtigen. Eine SQL-Löschung bedeutet nicht, dass bereits exportierte Dateien, externe Backups oder alle früher belegten Datenträgerblöcke sofort verschwinden. Der BfDI beschreibt in seiner eigenen Forum-Datenschutzerklärung eine konkrete Serverlog-Verarbeitung und Löschfrist. Daraus lässt sich keine allgemeine Frist für alle Webangebote ableiten; das Beispiel zeigt gerade, dass Betreiber die eigenen tatsächlichen Speicherzeiten benennen müssen. [BfDI-Forum: Datenschutz](https://forum.bfdi.bund.de/privacy) ### Betroffenenrechte Eine Export-/Löschfunktion erleichtert den Betrieb, ersetzt jedoch nicht den organisatorischen Prozess. Anfragen müssen auffindbar, der richtigen Person zuordenbar und nachvollziehbar bearbeitet werden. Rechte gelten jeweils unter ihren gesetzlichen Voraussetzungen; nicht jede Art von Daten ist automatisch portabel. Der EDPB nennt insbesondere Information, Auskunft, Berichtigung, Löschung, Einschränkung, Übertragbarkeit und Widerspruch sowie grundsätzlich einen Monat für die Reaktion. [EDPB: Rechte von Personen](https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_en) ## 5. Verantwortlicher, Hosting und AVV Der Websitebetreiber bestimmt die Zwecke seiner Website und ist regelmäßig für diese Verarbeitung verantwortlich. Bei tatsächlich weisungsgebundener Verarbeitung personenbezogener Daten durch einen Hoster oder Dienstleister kommt Auftragsverarbeitung in Betracht. Dafür sind Rollen, Weisungen, Sicherheit, Unterauftragnehmer, Unterstützungspflichten und Rückgabe/Löschung vertraglich zu regeln. Eine Software-Downloadseite macht ihren Entwickler nicht automatisch zum Auftragsverarbeiter für alle lokal betriebenen Installationen. [EDPB: Verantwortlicher und Auftragsverarbeiter](https://www.edpb.europa.eu/sme/learn-the-basics/data-controller-or-data-processor_en) Eine AVV-Vorlage sollte die wirkliche Architektur beschreiben und nicht bloß Gesetzestext wiederholen. Dazu gehören Datenarten, Betroffenengruppen, Verarbeitung, Hostingorte, Unterauftragnehmer, technische Maßnahmen und vereinbarte Rückgabe-/Löschregeln. [EDPB-Leitlinien 07/2020, Abschnitt 1.3](https://www.edpb.europa.eu/system/files_en?file=2023-10%2FEDPB_guidelines_202007_controllerprocessor_final_en.pdf) **Für diese Übergabe fehlen ohne Betreiberantwort weiterhin:** tatsächlicher Verantwortlicher, Anschrift, Kontakt, konkrete Hostingpartner/-orte, Log- und Backupfristen, gegebenenfalls Datenschutzbeauftragter sowie Rechtsgrundlagen und zuständige Aufsicht. Diese Angaben dürfen nicht erfunden werden. Eine öffentlich sichtbare Datenschutzerklärung mit Platzhaltern ist keine fertiggestellte Informationserfüllung. Für einen lokalen Entwurf kann der unvollständige Status offen angezeigt werden; vor einer geschäftlichen Veröffentlichung muss er beseitigt sein. ### Impressum § 5 DDG verlangt bei erfassten geschäftsmäßigen Diensten unter anderem ständig verfügbare, leicht erkennbare und unmittelbar erreichbare Angaben zu Name und Anschrift, bei juristischen Personen Rechtsform und Vertretung, elektronische Kontaktmöglichkeit und gegebenenfalls Register, Registernummer sowie vorhandene Umsatzsteuer- oder Wirtschaftsidentifikationsnummer. Zusätzliche Angaben hängen von Tätigkeit und Anbieter ab. [§ 5 DDG](https://www.gesetze-im-internet.de/ddg/__5.html) ## 6. Kostenlose Browsererweiterung ### Kleinstmögliche Berechtigungen `activeTab` erlaubt nach einer Nutzerhandlung vorübergehend Zugriff auf den aktuellen Tab. Für Script-Injektion ist zusätzlich `scripting` erforderlich. Es ist ein engerer Ansatz als eine dauerhafte Freigabe aller Websites. Der Zugriff ersetzt nicht die Notwendigkeit, den Zweck verständlich zu erläutern. [Chrome: activeTab](https://developer.chrome.com/docs/extensions/develop/concepts/activeTab) **Eigene Empfehlung:** Bei `activeTab` + `scripting` bleiben, keine `history`-, `cookies`-, `tabs`- oder ``-Freigabe für lediglich möglicherweise spätere Funktionen. axe lokal bündeln, nur per bewusstem „Seite prüfen“-Klick starten, keine Analysedaten an barrierex senden, Resultate nur flüchtig halten, Download ausschließlich auf Anforderung. Die kostenlose Erweiterung kann einen normalen Produktlink enthalten; sie darf den geprüften Websites nicht ungefragt Werbung hinzufügen. ### Chrome Web Store Die Store-Richtlinie verlangt eine zutreffende, aktuelle Datenschutzerklärung bei Umgang mit Nutzerdaten, transparente Angaben zu Nutzung/Weitergabe, den engsten erforderlichen Berechtigungsumfang und zweckgebundene Datenverwendung. Auch lokal analysierter Seiteninhalt sollte im Produkt erklärt werden; „keine Übertragung an den Anbieter“ ist eine andere Aussage als „keine Datenverarbeitung“. Store-Formular, öffentliche Erklärung und Verhalten dürfen einander nicht widersprechen. [Chrome Web Store Policies: Datenschutz](https://developer.chrome.com/docs/webstore/program-policies/policies) Eine Veröffentlichung setzt einen Entwickleraccount, vorbereitetes ZIP, Store-Eintrag, Privacy-Angaben und die Einreichung zur Prüfung voraus. Ein erzeugtes ZIP ist noch keine Store-Veröffentlichung. Bis zur Freigabe lauten passende Buttons „Erweiterung herunterladen“ und „Lokal installieren“, nicht „Im Chrome Web Store installieren“. [Chrome: Veröffentlichungsablauf](https://developer.chrome.com/docs/webstore/publish) ### Firefox / Mozilla Mozilla unterscheidet lokale Verarbeitung von Übertragung außerhalb der Erweiterung/des lokalen Browsers. Übertragungen sind zweckgebunden zu minimieren und benötigen die nach Richtlinie erforderliche Kontrolle bzw. Einwilligung. Die Bezeichnung „Werbemaßnahme“ für das Produkt rechtfertigt keine Übermittlung von besuchten URLs oder Prüfergebnissen an Marketingdienste. [Mozilla Add-on Policies](https://www.extensionworkshop.com/documentation/publish/add-on-policies/) Für neue Add-ons ist seit 3. November 2025 eine Erklärung über `browser_specific_settings.gecko.data_collection_permissions` vorgesehen. Bei tatsächlich vollständig lokaler Verarbeitung ohne solche Übertragung ist `required: ["none"]` die deklarierte Variante. Manifest V3 benötigt für die Signierung eine Extension-ID. Die Angabe muss zur realen Implementierung passen. [Mozilla: Manifest-Felder](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings), [Mozilla-Ankündigung](https://blog.mozilla.org/addons/2025/10/23/data-collection-consent-changes-for-new-firefox-extensions/) ```json { "browser_specific_settings": { "gecko": { "id": "barrierex-audit@REPLACE-WITH-PUBLISHER-DOMAIN", "strict_min_version": "140.0", "data_collection_permissions": { "required": ["none"] } } } } ``` Der Platzhalter ist eine ausdrückliche Konfigurationsstelle, keine veröffentlichte Anbieteridentität. Signierung und Store-Freigabe sind separate Schritte. ## 7. Technische Integration: kurze, recherchierte Ergänzung Diese Empfehlungen sind aus den offiziellen Integrationsmechanismen abgeleitet. Sie belegen noch keinen ausgeführten End-to-End-Test aller Framework-Versionen. | Stack | Sinnvoller Integrationspunkt | Quelle | |---|---|---| | Next.js App Router | `next/script` im Root-Layout, `strategy="afterInteractive"`; nicht als DOM-Widget in einen Worker verschieben | [Next.js Script Guide](https://nextjs.org/docs/app/guides/scripts) | | React 19 | Externes `` bewusst außerhalb der Astro-Bündelverarbeitung belassen | [Astro Scripts](https://v5.docs.astro.build/en/guides/client-side-scripts/) | | Angular | Globale HTML-Vorlage bzw. konfigurierte Script-/Asset-Einbindung, nicht unkontrolliert in jedes Komponenten-Template kopieren | [Angular Workspace-Konfiguration](https://angular.dev/reference/configs/workspace-config) | **Wichtig für den eigenen Widget-Code:** Der universelle Loader muss auf vorhandenes `document.body` warten können, weil async-/SSR-Ladestrategien unterschiedlich sind. Eine Singleton-Kennung vermeidet doppelte Launcher. Ein Destroy-/Reinitialisierungsweg erleichtert SPA- und Editor-Integration. Strenge CSPs benötigen passende Nonces/Stylestrategien; Kunden nicht pauschal zum Abschalten ihrer CSP auffordern. ## 8. Abnahmekriterien für die konkrete Umsetzung 1. Landingpage lädt bei frischem Browserprofil ausschließlich dokumentierte eigene Ressourcen; Video startet nach Klick, ohne Fremd-iframe. 2. Widget erzeugt ohne Interaktion keine Kennung und keine persistente Präferenz; optionale Speicherung ist sichtbar steuerbar und löschbar. 3. Vorlesen wählt ausdrücklich eine lokal ausgewiesene Stimme oder erklärt die Nichtverfügbarkeit. 4. Erweiterung verlangt nur tatsächliche Mindestberechtigungen, sendet Prüfergebnisse nicht an den Anbieter und enthält eine erreichbare Datenschutzerklärung. 5. Workspace-Export, Datenlöschung und gewählte Aufbewahrungsregeln funktionieren einschließlich gespeicherter Scan-Snapshots. 6. App-Logs enthalten keine Request-IPs, Geheimnisse, kompletten URLs oder DOM-Befunde; Hoster-/Proxylogs sind separat geprüft. 7. Betreiber- und Hostingangaben sind vor öffentlicher geschäftlicher Nutzung ergänzt; keine ungeprüfte Aussage „100 % DSGVO-konform“ oder „DSGVO-zertifiziert“.