Trust and isolation model
This page states what ShellCanvas verifies, what it merely contains, and what it asks you to trust outright. An early prototype earns trust by being precise about that last category rather than by implying it is empty.
How it works
Host identity comes before authentication
The host key is checked before any credential is sent. An unknown host stops the connection and shows you the fingerprint to accept or reject; a changed key is a hard stop, because it is what a redirected or intercepted connection looks like.
The trust store fails closed. If it is unreadable, malformed or truncated, connections are refused rather than continued without verification — a corrupt file must never quietly degrade into trust-on-first-use.
Credentials stay below the line
Passwords, passphrases and key material are handled in the native layer and are not written into saved host profiles, workspace files or app storage. The interface never receives them. Adapter configuration follows the same rule: a password field may not carry a packaged default, and its value is not persisted into a saved profile.
Apps are contained; native extensions are trusted
| Extension | Runs as | Isolation | What is verified |
|---|---|---|---|
| App | Sandboxed webview | No filesystem, network or session access of its own; every capability is brokered and granted | Webview isolation, Windows only |
| Theme | Data, not code | Tokens applied by the shell | Schema validation |
| Connection adapter | Native process | Separate process; 4 MiB frames, 32 requests in flight, bounded deadlines | Package hashes only |
| Filesystem bridge | Native process | Separate process; rooted paths, 1 MiB frames, 32 KiB chunks | Package hashes only |
Apps get capabilities only through the broker, which checks the app's grants and the workspace's bindings on every call. Grants are per capability and, for custom services, per service; storage is per app; network access is an allowlist you approve.
Native extensions are a different kind of thing. Their packages are hashed with SHA-256 and re-verified before every launch, so what runs is exactly what you reviewed and nothing altered it afterwards. That establishes what, never who: there is no publisher authentication, no signing, no marketplace and no review. A connection adapter runs with your operating-system permissions. Install one because you trust its author, not because ShellCanvas approved it.
Diagnostics are redacted by design
The connection diagnostics report is a timeline of host-observed events — preparation, launch, dispatch, outcome, exit — with sequence numbers, timings, request ids and error codes. It deliberately excludes configuration values, launch arguments, executable paths, method names, payloads, adapter error text and process output, so it can be attached to an issue without a review pass. It holds the newest 256 events for up to 32 connections and is cleared when the desktop restarts; there are no log files to sweep for secrets afterwards.
Uncertainty is reported, not resolved
When the core cannot tell whether an operation took effect — a lost acknowledgement, a retired transport, an unconfirmed close — it reports the outcome as uncertain instead of choosing the convenient answer. The same discipline applies to cleanup: an unconfirmed process tree keeps its files reserved rather than being assumed dead.
Boundaries
What is validated: host-key verification and fail-closed trust handling, package hash verification, the app permission model, and webview isolation on Windows. Isolation behaviour on other platforms has not been verified.
What is not claimed: webview isolation is not a certification against a deliberately hostile app. Native adapters and bridges are not sandboxed at all. There is no supply-chain verification of any extension. Desktop installers are currently unsigned, which Windows will tell you during installation. ShellCanvas has had no external security audit.
What is out of scope: ShellCanvas does not protect a destination from a user who is authorised to reach it. It is a client, and it inherits whatever the remote account can do.
Related guides
- Extension permissions and trust — the same model as a user decision.
- Make your first connection — accepting a host key.
- System architecture — where each boundary sits.
- Report a reproducible issue — including how to report a suspected vulnerability.