Podkey's fetch/XHR interceptors unconditionally set Authorization on
every outbound request, replacing whatever the page already put there.
Pages using Solid-OIDC (Authorization: DPoP <token>) have their auth
silently swapped for Podkey's NIP-98 signature — the server then
authenticates as did:nostr:<podkey-key>, doesn't match the user's
real WebID, and denies access. User gets 403 on their own pod.

Fix: before injecting NIP-98, check whether the page already set
Authorization. If yes, step aside and let the page authenticate
itself. If that auth gets a 401, the existing retry-on-401 path
still tries NIP-98 as a fallback.

Covers both fetch (options.headers across Headers/object/array shapes)
and XHR (via a setRequestHeader override that tags the request).

New hasAuthorizationHeader helper is canonical in src/auth-header-utils.js
with unit tests. The in-page scripts duplicate it because they load as
classic scripts without ESM imports.

…ting-auth

Don't overwrite existing Authorization headers (#5)

…rial

crypto-browser.js contained a completely broken "Schnorr" implementation that:
- Derived public keys via SHA-256(private_key) instead of secp256k1 scalar multiplication
- Created "signatures" as SHA-256(private_key || event_id) duplicated to 128 hex chars
- This means signatures contained material directly derived from the private key,
  enabling private key recovery through known-plaintext analysis

While the file is not imported in the current bundled build (background.js imports
from crypto.js which uses @noble/secp256k1), its presence in the source tree is an
active hazard: any future refactor, build configuration change, or browser field
mapping in package.json could silently activate this broken implementation.

The correct implementation lives in src/crypto.js using @noble/secp256k1 with
proper Schnorr signatures per BIP-340 / NIP-01.

Co-Authored-By: claude-flow <ruv@ruv.net>

MV3 has restrictive CSP defaults, but an explicit policy documents the
intended security posture, prevents accidental relaxation during future
development, and makes the extension's trust boundary auditable at a
glance.

Co-Authored-By: claude-flow <ruv@ruv.net>

The webRequest permission is declared but never used — the code
explicitly notes that webRequestBlocking is deprecated in MV3 and uses
JavaScript-level fetch/XHR interception instead. Removing this
permission reduces the extension's privilege surface and avoids
triggering unnecessary review during Chrome Web Store submission.

Co-Authored-By: claude-flow <ruv@ruv.net>

The privateKeyToNsec, nsecToPrivateKey, and publicKeyToNpub functions
emitted fake nsec_<hex> / npub_<hex> strings that are not valid NIP-19
bech32 encoding. These stubs could confuse users into thinking they
have a valid key backup, and any interoperability with other Nostr
clients would silently fail.

The functions are not imported or called anywhere in the codebase, so
they are removed entirely rather than replaced with throwing stubs.
Proper NIP-19 bech32 support can be added when needed via a bech32
library.

Co-Authored-By: claude-flow <ruv@ruv.net>

Replace innerHTML template literal interpolation with DOM API methods
(createElement, textContent, appendChild) when rendering the trusted
origins list. The previous code interpolated the origin string directly
into HTML, allowing an attacker who injects a malicious string into the
trusted origins (e.g. <img src=x onerror="...">) to execute arbitrary
JavaScript in the popup's privileged extension context, potentially
exfiltrating the user's private key.

Co-Authored-By: claude-flow <ruv@ruv.net>

…llback

security: remove crypto-browser.js (broken Schnorr leaks private key)

security: add explicit Content Security Policy to manifest

fix: remove unused webRequest permission

security: sanitize HTML in popup trusted-origins list (XSS fix)

fix: remove broken bech32 nsec/npub stub functions