Inline extension interactions

Proposal, not an available feature. No network permission or new data collection is enabled. These RFCs are locally prepared; remote review/merge awaits the owner repository.

Current architecture

The extension currently uses activeTab and explicit click-to-fill. New review UX confirms the exact origin, but no content-script inline menu is installed.

Design under review

Add optional per-site host permission only when the user enables inline help. Use an isolated, keyboard-accessible menu with no decrypted suggestions until the user unlocks. Validate origin, frame, form destination and page changes before releasing a value; generated passwords should enter the vault only after user confirmation. Keep vault unlock in a trusted extension surface and treat webpage messaging as hostile. Passkey mediation depends on RFC 8.

Milestones

1. M1: permission/iframe/message threat model and hostile-page harness
2. M2: accessible inline login/generator prototype with limited host grants
3. M3: real Chrome/Firefox runtime tests, store policy review and passkey integration separately

Required acceptance tests

• Page scripts cannot spoof an unlock prompt or request arbitrary vault fields
• Cross-origin frames and navigated tabs cannot receive credentials
• Keyboard, zoom, reduced-motion and permission revocation remain usable

Limits

No broad all-sites host permission or persistent background unlocked vault is introduced by this RFC.

Any implementation must preserve local unlock/export, add KDBX/KeePassXC regressions for crypto/format changes and update privacy disclosures before new data flows begin.

← All 41 workstreams