Hugs
A hug is code a team brings. CliqHub runs it on the Hug page, next to people’s data, so it is boxed in: it can draw,
and talk to the host — nothing else.
What it is protected against
The sandbox
The page loads in<iframe sandbox="allow-scripts"> — no allow-same-origin, allow-forms, allow-popups,
allow-top-navigation, allow-modals or allow-downloads — from the content host, with:
blob:) — and nothing more.
The content host
On cliqhub.io, pages are served fromcontent.cliqhub.io, at /hb/<sha256>/…. It serves only bundle files, sends
no cookies and receives none. A local cliqd serves pages itself, with the same headers.
Talking to the host
Everything a page does outside its frame is a message to the host (bridge protocol), which checks it:- messages only from the page’s own frame;
- answers of at most 256 KB; files only ones the host gave it, for declared upload slots;
- reads only of the Hug’s attachments, the viewer’s own uploads, and the files of the answer being shown;
- a Submit label of at most 40 characters;
- rate limits: 20 answer updates a second, one file picker and one link dialog at a time, 10 reads at once and 50 MB per page.
Who is trusted for what
- CliqHub is trusted about who answered, when, through which channel, and which files they uploaded.
- The definition is trusted about what they answered — the agent checks every answer with it before acting.
- The daemon is the realm’s boundary, as for running agents: a daemon that can open Hugs can already ask anything
with
form. That’s why there’s no registration of hugs: a custom page adds no reach a form doesn’t have, and the sandbox limits what it can do.
Writing a safe hug
- Put everything in the bundle; pass data in params and files as attachments.
- Never put secrets in params — they’re shown to everyone who can see the Hug.
- Use
html(or React) rather than building HTML strings, so values are escaped. - Keep the rules in the definition, not only in the page.