Docs / Safety

Safety/

A PlanReview link opens someone else’s HTML document. We treat every plan as untrusted and contain it so that opening one is closer to reading a page than running a program. Here is exactly what that containment does — and what it does not promise.

What a plan can and cannot do

Plans are self-contained HTML. Most are inert documents; some carry small scripts for things like copy buttons and tabs.

A plan can

Render HTML and CSS, and run small self-contained scripts inside a sandboxed frame.
Update the page it is drawn in — toggle tabs, copy text to your clipboard, reveal sections.
Open a link you click in a new tab, the same as any web page.

A plan cannot

Reach the network through the ordinary channels — fetch, XHR, WebSocket, and beacon are all blocked.
See other sites, your cookies, or any PlanReview account or session.
Navigate the top window or embed another site, form, or frame.
Persist anything — no local storage, no cookies, nothing left behind.

Why PlanReview links are contained

Containment is enforced by the browser and the server together — it does not depend on the plan behaving.

Sandboxed frame: isolated; Every plan renders inside a sandboxed iframe with no access to the surrounding page, your PlanReview session, or any other origin.
Network policy: blocked; A strict Content-Security-Policy blocks the ordinary outbound connections and external subresources, so a plan cannot phone home or pull in third-party code through the usual channels.
Rejected at upload: checked; Uploads that embed frames, forms, external resources, or other escape hatches are rejected outright — they never get a link at all.
Static by default: off; Scripts do not run unless a plan has earned the interactive lane. Until then it serves as a plain, non-executing document.

How network access is limited — not eliminated

Keeping a plan off the network is layered work. No single layer is a guarantee; together they make outbound activity hard to reach and likely to surface for a person.

Browser policy: blocked; The page’s policy blocks the ordinary outbound channels — fetch, XHR, WebSocket, and beacon — so a plan cannot open a connection the normal way.
Upload validation: rejected; Submitted markup that references an external resource is rejected before it earns a link, so nothing loads from a third-party origin.
Script scanning: flagged; Scripts are parsed and inspected for network or navigation behaviour. Anything the automated check will not vouch for is routed to a person before it can run.

These layers reduce network risk; they do not prove its absence. A covert or residual channel is always conceivable, so approval is risk mitigation and human judgement — not a mathematical guarantee of zero network activity.

What a human reviewer may inspect

When a plan asks to run scripts that our automated check will not vouch for, a person decides.

The reviewer reads the plan’s own source and content — the HTML and the scripts it carries — while it is still serving as a static document. Reviewing never runs the plan. There is no user database to consult and nothing about you is involved: the review is about the code in the document, not the person who opened it.

What approval means — and doesn't

Approval is a human judgement, not a guarantee.

✓

Approved

A person looked at this plan’s code and judged it acceptable to run inside the sandbox. Change the scripts and approval does not carry — the new code serves static until it is reviewed again.

Not a safety promise

Approval means a human judged the plan acceptable — it is not a guarantee that the plan is safe or correct. The containment above is what actually limits what any plan can do; use your own judgement about the content, as you would with any link.

↺

Reversible

Approval can be revoked at any time. Revoked plans fall back to serving as static documents on their next load.

This page describes current behaviour and is not a warranty. If you believe a plan is abusing a link, report it and we will review it.