fix(extension): take the origin from the browser, not from the message body

[stormer78]

Prerequisite for putting a consent surface in this extension. A surface that renders "do you approve this, for this site" is only as trustworthy as its idea of which site is asking — and right now that idea comes from the site.

The defect

Every origin decision in the background — isOriginTrusted, trustOrigin, checkOriginPin, pinOrigin, and what the consent prompt names — reads req.origin, a field the content script placed in the message body.

The sender.id === chrome.runtime.id check above it proves the message came from this extension. It says nothing about which page it came from. Every content script (the manifest injects across <all_urls>), the popup, the options page, the consent window and the offscreen document all pass it.

So the origin was a claim by an untrusted party about itself — and isOriginTrusted honoured claims. Asserting origin: "https://bank.example" was enough to be handed the silent bypass the user had granted that site by ticking "remember".

Today this is defence-in-depth rather than a live exploit: content_scripts omits all_frames, and content.ts rejects event.source !== window. But a compromised renderer is precisely what a content script is meant to survive, and under a generic task relay this value decides whether a DID gets deactivated.

The fix

Take sender.origin — browser-attributed, not forgeable by page content — and overwrite whatever the body claimed. Done once at the message boundary, so every consumer downstream becomes trustworthy without touching any of them.

It is not the one-liner it looks like. sender.origin alone is insufficient: an extension-internal sender reports chrome-extension://<id>, which is a perfectly real origin and would sail through any check that merely asked "is an origin present?". So a page-facing message must also have a tab behind it, and one that doesn't is refused — there is no legitimate sender for that.

attestedOrigin lives in @openvtc/pnm-core, not the extension: it's pure, the extension package has no test harness at all, and a mobile agent's IPC bridge will need to hold itself to the same rule.

Two more in the same area

signTrustTask prompted for nothing and discarded the origin it was handed. It is the most powerful method on the page-facing surface — it signs an arbitrary envelope with the holder key.

The ergonomic argument in the comment ("per-signature prompts would be crippling for normal RP usage") is sound. But "don't prompt a site the user has connected" is not "don't prompt anyone". As written, any page could obtain a signature over anything — which under a generic task relay is a straight bypass of the VTA's policy engine: why go through a gate that can require consent, when you can ask the wallet to sign whatever you like?

Now gated on the attested origin, naming the task type it is being asked to sign. A site the user has already connected short-circuits inside gatedConsent and still sees no prompt, so the ergonomics survive.

The content script's method ternary ended in : RUNTIME_LOGIN — so any method name it didn't recognise (a typo, a future method this build predates, anything a page cared to invent) silently became a login request. Now an explicit table that fails closed.

Also

Repairs the lockfile — npm ci has been failing since @openvtc/vti-tsp-js was added without it (#80). This repo has no CI, so nothing caught it, and nothing is checking any of the above either. Worth fixing separately; I'd suggest at minimum npm ci && npm run build && npm run lint && npm test on PRs.

Tests

Five new cases in core covering attestedOrigin, including the one that matters: a sender with no tab has no attested origin whatever origin it reports — the chrome-extension:// case that a naive presence check would wave through.

npm ci, npm run build, npm run lint, npm test (75 passing) all clean.