Trust and security

Apps act as the member

An app is trusted, the same as an extension. When a member opens it, it acts as them:

• its pages, worker and tools read and write the tables of its space as the member;
• it can run the member’s routines for it, start agent threads for them and send them notifications;
• its worker, run server and tools are code running on the member’s computer, as them.

Each app has an origin of its own on Matter’s local proxy, and Matter admits requests to it only from the app’s own pages and processes.

Every version is signed

Every version of an app is signed with a signing key registered in the workspace. The server refuses a version without a valid signature. Each member’s Matter checks the signature again, on their own computer, before it runs any of the version.

A key stands for its publisher: the member who registered it. Every version signed with it is theirs, whoever deployed it. When Sam shares a key with Ana, Ana’s deploys with it still say they’re Sam’s: Versions shows “Sam (deployed by Ana)”. Sam can have several keys (one per computer, one for CI), and they’re all Sam’s.

The trust prompt

Trust is in a publisher. The first time someone opens an app from a publisher they haven’t trusted on this computer, the app’s page asks, in place of the app: Trust apps from Sam? It says that apps they trust act as them: they can change the tables in their space and start chats with their agents, and, for an app with a worker, a run server or tools, run their own code on this computer.

• Trust opens the app. Trusting a publisher trusts every app signed with any of their keys, and every new version of each: updates never ask.
• To leave it closed, go anywhere else, or choose Go back. The question waits on the app’s page.

Your own versions, published by you or signed with a key on your computer, never ask you. Until a publisher is trusted on a computer, the workers and run servers of their apps stay stopped there, and their routine runs there stop at once, saying the app isn’t trusted.

A member can stop trusting a publisher with Stop trusting Sam in the menu of any of their apps. Their apps stop, and Matter asks again the next time one opens. Trust is kept on each computer.

Unsigned and revoked versions

A version that isn’t signed with a registered key doesn’t open. Its page says so, and asks whoever deploys it to deploy it again.

When a key is revoked, or its publisher leaves the workspace, every version it signed stops on every computer, at once, including open ones. Each app runs again once someone deploys it with another key. Members who trusted the publisher don’t need to again; another publisher’s key asks about them.

Secrets

Anyone who can see an app can download its bundle, with matter app pull. So never put tokens or keys in the deployment.

• Third-party services should come through the member’s own connections in Matter, which routines get as tools. See Connected apps.
• An app’s own tools may call whatever they like, using the member’s own settings.
• Keep what a process writes in MATTER_DATA_DIR, on the member’s computer.
• Keep signing keys out of the project and its repository. In CI, give the key as a secret (MATTER_SIGNING_KEY).

Sites that need the member signed in

For a site that needs the member signed in, have the routine drive the member’s Chrome: add "needs": ["browser"] to it. The routine works there as the member, and never sees their password.

The routine should notice when a login is needed, pause that account, and tell the member with matter.notify. That’s what Prospector does: its runs pause an account that’s signed out or hits a security check, its approved actions wait, and the member gets a notification and a Resume button.

Run servers

A run server listens on the loopback address only (HOST, 127.0.0.1), and must not trust headers it didn’t check. Matter strips any x-matter-* headers and its own cookie from what it forwards, and signs what it tells the server about each request. Check the signature with matter.verifyRequest before you use it.

Not yet

Apps are internal tools for now: an app’s pages run with the member’s access to its space, unsandboxed, and it can do whatever the member can. Sandboxing, and permissions an app asks for, come with publishing apps outside a workspace.