v1.2.0 - Major Security Update

[1.2.0] — 2026-08-01

Credential security release. Headers that carry credentials are now recognised,
scoped, and stored separately from the rest of your configuration. One new
permission: alarms, used solely to schedule the vault auto-lock.

Existing profiles keep working. Nothing is deleted, and you choose how your
credentials are stored the first time you open the popup after updating.

Added

Credential detection

• Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-API-Key,
  API-Key, X-Auth-Token, X-Access-Token and vendor variants such as
  X-Acme-Api-Key are recognised case-insensitively
• A shield button on every header row marks anything else as a credential,
  because no built-in list covers every vendor's naming
• Cookies created in the cookie editor are treated as credential-bearing

Host restrictions

• A credential-bearing header will not activate until its profile has a real
  URL or host filter. A bare * or <all_urls> does not count
• If you need one everywhere, a per-profile override accepts the risk for that
  profile alone and leaves the rest protected
• A warning when a credential targets a plain http:// host, with local
  development addresses exempt
  Three credential-storage modes
• Session only (default) — memory-only, cleared when the browser session
  ends. Profiles survive and simply ask for the credential again
• Encrypted vault — AES-GCM, key derived with PBKDF2 (600,000 SHA-256
  iterations), unique salt per vault and unique IV per secret. Unlocked with a
  passphrase after each restart
• Persistent plaintext — not recommended — the previous behaviour, kept for
  people who need it, behind an explicit confirmation

Vault locking

• Locking freezes every profile that holds credentials: rules stop applying and
  the profile cannot be viewed or edited. Profiles without credentials keep
  working and stay editable
• Auto-locks after a configurable period of inactivity, 15 minutes by default,
  measured from your last deliberate credential action. Network traffic does
  not hold the vault open
• Scheduled with the alarms API and verified against a stored timestamp, so a
  suspended background worker or a late alarm cannot leave it unlocked
• A Lock now action in the title bar and in the settings panel
• Change the passphrase, which re-encrypts every credential in one write, or
  reset the vault, which deletes them after a clear warning

Viewing credentials

• An eye button reveals a stored credential inline, and an eye-with-a-slash
  hides it again. Revealed values are cleared when the vault locks
• Unlocking is the authentication step, so an unlocked vault does not ask
  again. An optional strict mode, off by default, re-derives the key from a
  freshly typed passphrase for each reveal

Safer export, clipboard, and duplication

• Exports offer configuration only (the default), an encrypted backup, or
  plaintext with an explicit warning
• Clipboard copies omit credentials by default, and note that clipboard history
  tools may retain anything you do copy
• Duplicating a profile offers configuration only (the default), reusing the
  same stored secret, or creating an independent one
• Deleting a profile never removes a credential another profile still uses;
  genuinely unused ones are cleaned up
• Imports detect omitted, plaintext, and encrypted-backup credentials, never
  activate plaintext ones silently, and re-check host restrictions

Changed

• Interface icons are now inline SVG. Emoji picked up the system colour
  font and rendered differently on every platform
• Security moved out of the section tabs into a dedicated settings view
  reached from the title bar. It is app-level configuration, not per-profile
  content, and the tab strip is for the current profile
• The popup is wider, 700px instead of 620px, so all six section tabs show
  their full labels
• Profiles now reference credentials by identifier rather than storing the
  value inline, so a shared credential exists once rather than being copied
• Storage schema is version 3. Version 2 files still import correctly
• Unlocking caches only the derived key. Credentials are decrypted on demand
  rather than written to session storage as a readable set

Fixed

• Non-credential header rows displayed the text null where the credential
  control belongs
• Renaming a header to a credential-bearing name mid-edit left the plain value
  field in place, so a credential could be typed directly into the profile
• A credential-bearing header with no stored secret could be applied using
  whatever inline value it carried. It is now withheld
• Unlocking the vault did not refresh the interface until the popup was
  reopened, because a failed background notification aborted the redraw
• Section tab labels were clipped at the previous popup width

Migration

On first launch after updating, any credentials stored inline are detected and
you are asked to choose a storage mode, including staying on persistent
plaintext. Old Chromium dynamic rules holding credentials are removed at the
same time so a stale rule cannot stay active beside a new one. The migration is
idempotent and safely resumes if interrupted. Profile names, filters,
exclusions, ordering, enabled state, redirects and non-sensitive headers are
preserved exactly.

Known limitations

• Encryption protects credentials at rest. While the vault is unlocked the
  key is necessarily in memory, so anything running with that level of access
  can read them. Host restrictions are the protection that still applies in
  that case. See SECURITY.md
• On Chromium a missing credential withholds the whole sensitive rule; on
  Firefox only the protected header operation is skipped. This follows from the
  difference between declarativeNetRequest and webRequest
• Session-only and encrypted-vault modes need storage.session, present in
  Chrome 102+ and Firefox 115+. If it is unavailable the extension fails closed
  rather than storing a credential persistently

---