Where the Target page's own JavaScript runs, and what it can reach

[stueydubs]

Question

When webtweak is a website rather than a local server, what origin does the Target page's own JavaScript run in, and what can it reach?

Supersedes #16, which asked the same underlying question of a runtime that no longer exists. #16 is closed, and its reasoning is worth reading before starting here: it establishes that a page which can forge requests is the real adversary, and that reloading a tab evicts neither a hostile document nor a service worker.

Why this is sharper under the new runtime, not softer.

Under the local server, a hostile Target page was same-origin with the server, so its reach was the served Project. Under a hosted app the blast radius is potentially wider, not narrower: if the Target page renders inside the app's own origin, its scripts inherit whatever the app holds - which is every directory handle the user has ever granted, not just the Project currently open. A capability the browser deliberately gates behind a user gesture is then reachable by page script that never asked anyone.

Against that, one thing genuinely improves: the folder picker is the browser's, and the browser enforces the user gesture. That is the honest answer to #16's folder-dialog-abuse item, and it is enforced by someone other than webtweak.

Resolve:

• Whether the Target page renders in an origin distinct from the app's, and by what mechanism.
• Whether a sandboxed iframe is sufficient, and which sandbox flags are required for the page to still render as itself. Note the tension: the page needs its own scripts to run to look right, and those scripts are the adversary.
• Whether a directory handle can leak across that boundary - postMessage, structured clone, or any other path.
• Whether granting a second Project widens what an already-running hostile page can reach, which is Is switching Project a privileged act #16's original question restated for this runtime.
• What happens to a service worker registered by a previously-edited page, given the app's origin is now fixed and public rather than a rotating loopback port. The origin no longer rotates at all, so the mitigation that answered this under the server design is unavailable.
• Whether the Overlay and the Target page can share a DOM at all, or whether the Overlay must sit outside the frame the page renders in.
• What the honest statement of the trust boundary now is. The "The served page is trusted, and that is the tool's real trust boundary" decision in CONTEXT.md describes a server that will not exist, and must be rewritten rather than quietly left in place.

Blocked by #19, which establishes what isolation the browser actually offers and whether handles can cross it.