Tripwire — Requirements

Goals

• Give a user a manual confirmation step before a guarded page fires a risky form submit or button click.
• Treat a human-triggered action and a script-triggered action the same way: both get paused if the site is guarded.
• Keep a local, inspectable record of what got paused and what got let through.
• Stay off by default everywhere except the sites a user explicitly turns it on for.

Primary user

Someone who runs one or more AI browser extensions or an agentic browser feature alongside their normal browsing, and wants a checkpoint before that automation can complete a purchase, send a message, or delete something on a site they use for anything that matters (banking, shopping, work tools). They don't need this on every site, just the ones where a wrong click is expensive to undo.

Functional requirements

• FR1: The popup shows the hostname of the active tab and a toggle to guard or unguard that site.
• FR2: Guard state persists per-hostname in chrome.storage.local and survives a browser restart.
• FR3: On a guarded site, the content script intercepts native submit events on every form via a capture-phase listener.
• FR4: On a guarded site, the content script intercepts click events on buttons, submit inputs, and elements with role="button" whose visible text or aria-label matches a risk-keyword list (buy, purchase, pay, checkout, send, transfer, delete, remove, cancel subscription, deactivate, close account, and similar).
• FR5: In Strict sensitivity, the same keyword match also applies to anchor (<a>) clicks; in Balanced sensitivity, links are not intercepted.
• FR6: An intercepted action shows an in-page overlay naming the action and offering Allow or Block.
• FR7: Choosing Allow re-fires the original action (form submission or element click) without re-triggering the interceptor.
• FR8: Choosing Block discards the action; nothing happens on the page.
• FR9: Every intercepted action, allowed or blocked, is appended to an audit log entry with site, action label, kind, verdict, trigger, and timestamp.
• FR10: The popup lists the most recent audit log entries and today's paused/allowed counts.
• FR11: The popup lets a user switch sensitivity between Balanced and Strict; the setting applies globally, not per-site.
• FR12: The content script re-reads guard and sensitivity state on chrome.storage.onChanged so a toggle takes effect without a page reload.
• FR13: The extension declares no permission it does not use in content.js or popup.js.
• FR14: The demo harness reproduces the popup UI and the pause/allow/block flow without any chrome.* API, using the same markup, popup.css, and popup.js.
• FR15: The demo runs from a direct file:// open with no local server, falling back to an inline JSON snapshot if fetch is blocked.

User stories

• As someone who just installed an AI shopping assistant extension, I want checkout pages to pause before the assistant submits an order, so that I get a last look before money moves.
• As someone testing an agentic browser feature for the first time, I want to see exactly which of my clicks or its clicks got paused, so that I can tell how often it's trying to act without me noticing.
• As a user who trusts a specific site completely, I want to leave it unguarded, so that Tripwire doesn't get in my way there.
• As a user, I want a Strict mode for my banking site specifically, so that even a "Confirm" link gets a checkpoint, not just buttons and forms.
• As a user, I want to see today's paused-vs-allowed count at a glance, so that I know whether Tripwire is actually catching anything on my normal browsing.
• As a user evaluating whether to pay, I want to hit the three-site limit on the free tier before I decide it's worth $5/month, so that the upgrade makes sense to me rather than being forced early.

Extension surfaces

• Content script — capture-phase interception of submit and click on guarded sites; renders the confirm/block overlay; reads and writes chrome.storage.local
• Toolbar popup — per-site guard toggle, sensitivity switch, today's stats, recent audit log
• chrome.storage — persists guarded sites, sensitivity, and the audit log shared between the content script and the popup

Non-functional requirements

• No guarded-site data or audit log ever leaves the device; everything lives in chrome.storage.local.
• The content script does nothing measurable on an unguarded site beyond two passive document-level listeners.
• The overlay renders inside a dedicated host element and does not rely on the host page's CSS, so it can't be visually broken by the page it's guarding.
• Audit log is capped at 50 entries to keep chrome.storage.local reads fast and bounded.
• Popup interactions (toggle, sensitivity switch) reflect in the UI in under 100ms on a typical machine.

Out of scope (for the prototype)

• Distinguishing a genuine user click from a script-dispatched click via the Event.isTrusted flag (see Roadmap in README)
• Per-site optional permissions instead of the blanket <all_urls> content-script match
• Any paid tier functionality (sync, export, team policy) — the prototype is the free-tier feature set only
• A configurable, user-editable risk-keyword list (currently fixed in code)

Open questions

• Should the risk-keyword list be per-language, or is an English-only list an acceptable v1 limitation?
• Does re-dispatching a blocked form's submit on Allow ever conflict with a page's own JS-driven submit handler (e.g., one that does client-side validation before calling form.submit())?
• Is a global sensitivity setting sufficient, or do users want per-site sensitivity once they're guarding more than one kind of site?