How the security works

The record tables, the user accounts and the sessions are closed to the public key — not “partly protected”, but with no policy that permits access at all. Which means: even if everything running in the browser were exposed, not one row could be read with it.

Every table has four rules — who reads, who creates, who updates and who deletes. The rule is checked on the server on every request, and when it is “only the creator”, the filter goes inside the query itself. A mistake returns zero rows, not somebody else's rows.

A rule the model writes that is not in the vocabulary the server knows is not saved: it is replaced with the safe default for that action. The full detail is in who sees what.

Every session is stored with the id of the app it was issued for. A token taken from one site is treated on another as anonymous — not as an error, simply as somebody who is not signed in.

Signing up to an app grants nobody the admin role. The admin role comes only from the owner's screen, or in advance in a personal invitation — because signing up is a public door, and an app is live from its first build.

A built site holds no secret, and its policy lets it call our server and nothing else. External information — Shabbat times, exchange rates — arrives through us rather than from it, so there is no key in the site to steal.

The sites sit on a separate domain name from the system, so code running in a built site cannot reach your account here.

A project's id appears in the address, which is exactly why it never grants access on its own. A request for a resource you may not touch gets “not found” rather than “not permitted” — because the second answer confirms that the resource exists.

The same principle applies to signing up: an e-mail address that is already registered gets exactly the same answer as a new one, and nothing is sent to it — otherwise the form would become an instrument for finding out who is registered with you.