26c01a4fc3
Vorschlagsliste: Bisher galt jedes E-Mail-Feld als Anmeldefeld (isUsernameField gibt bei type=email bedingungslos true zurueck), und das Dropdown liegt mit maximalem z-index direkt unter dem Feld. Auf Seiten mit eigener Auswahlliste - etwa einem Benutzer-Picker - verdeckte es deren Treffer, die dadurch nicht mehr anklickbar waren. Zwei Regeln davor: Felder mit eigener Vorschlagsliste (ARIA-Combobox mit aria-autocomplete/aria-controls/aria-expanded oder <input list>) bekommen keine Vault-Vorschlaege mehr, sofern autocomplete sie nicht ausdruecklich als Anmeldefeld ausweist. Und sobald der Nutzer selbst tippt, blendet sich die Liste aus und bleibt es, bis das Feld wieder leer ist. 2FA-Code bereitlegen: Nach dem Ausfuellen eines Eintrags mit 2FA bleibt dieser fuenf Minuten vorgemerkt. Taucht danach ein 2FA-Feld auf oder wird es fokussiert - auch auf einer Folgeseite -, wird ein frischer Code geholt und in die Zwischenablage gelegt, statt wie bisher nur einmal zum Fuellzeitpunkt (wo er bis zum 2FA-Schritt laengst rotiert waere). Automatisch wird ausschliesslich kopiert; ins Feld geschrieben wird ein Code weiterhin nur bei ausdruecklicher Auswahl. Geschrieben wird zuerst ueber die Seite und, falls diese keinen Zugriff bekommt, ueber das Offscreen-Dokument des Hintergrunds. Abschaltbar in den Einstellungen. Beim Sperren des Tresors werden Vormerkung und ausstehender Fuellauftrag verworfen. Der Seiten-Scan des MutationObservers laeuft jetzt gedrosselt statt bei jeder einzelnen Mutation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G12DRMpe4UjYDwuRU1sjy1
2.6 KiB
Berechtigungen – Begründung
Diese Übersicht erklärt jede angeforderte Berechtigung (auch für die Chrome-Web-Store-Prüfung).
host_permissions: ["<all_urls>"]
Warum: Ein Passwort-Manager muss Login-Felder auf beliebigen Websites erkennen und auf Wunsch ausfüllen können. Deshalb ist Zugriff auf alle URLs erforderlich.
Was NICHT passiert: Es werden keine Seiteninhalte gelesen, gespeichert oder übertragen – ausschließlich Formularfelder (Benutzer/Passwort/OTP) werden erkannt und beim Ausfüllen beschrieben. Diese verlassen den Browser nicht. Es findet kein Tracking und keine Analyse statt.
content_scripts (matches <all_urls>, run_at: document_idle)
Warum: Das In-Seite-Dropdown mit Vorschlägen und die Felderkennung laufen als Content-Script. Notwendig für Autofill und die 2FA-Erkennung (inkl. Shadow-DOM und mehrstufiger Logins).
scripting
Warum: Werte werden über den nativen Value-Setter gesetzt und Events ausgelöst, damit auch React/Vue/Angular-Formulare die Eingaben übernehmen.
activeTab
Warum: Zugriff auf den aktiven Tab beim Ausfüllen aus dem Popup („Auf dieser Seite ausfüllen").
storage
Warum: Lokale Speicherung von Server-URL, Zugriffstoken (per SSO) und Einstellungen; Entsperr-Status in
storage.session.
alarms
Warum: Zeitgesteuertes Leeren der Zwischenablage (~30 s) sowie periodisches Verwerfen des Einträge-Caches (5 Min).
offscreen
Warum: In Manifest V3 hat der Service Worker keinen DOM-Zugriff. Zum programmatischen Leeren der
Zwischenablage wird ein kurzlebiges Offscreen-Dokument (Reason CLIPBOARD) genutzt – sowohl zum
Bereitlegen eines 2FA-Codes als auch zum anschließenden Leeren.
identity
Warum: Für die SSO-Anmeldung (chrome.identity.launchWebAuthFlow, OAuth 2.0 + PKCE). Öffnet die
OpenNIT-Login-Seite und empfängt die Weiterleitung an https://<extension-id>.chromiumapp.org/. Es wird
kein Zugriff auf Google-Konten o. Ä. genommen – nur der Web-Auth-Flow zur konfigurierten OpenNIT-Instanz.
Bewusst NICHT angefordert
tabs– entfällt: Die aktive Tab-Adresse ist bereits überhost_permissionsverfügbar. Dadurch erscheint keine „Browserverlauf lesen"-Warnung.- Keine
cookies,history,webRequest,downloads,notificationso. Ä.
Single-Purpose-Erklärung (für den Store)
OpenNIT Vault dient einem einzigen Zweck: dem Verwalten und automatischen Ausfüllen von Zugangsdaten und 2FA-Codes aus einer selbst gehosteten OpenNIT-Instanz. Alle Berechtigungen dienen ausschließlich diesem Zweck.