Local-first by design. Your work content never reaches our servers.
Pre-launch, no security certifications yet. Security contact to be published before launch.
Where your data lives
Your deviceSatin runs here
The app’s API
e.g. Jira Cloud
Token relay
Jira sign-in only
Satin cloud
Account and sync
- Lives
- In memory, and a short-lived cache on your device
- Leaves
- Fetched straight from the app’s API. Never sent to Satin
- Kept
- Cache cleared when you disconnect
Six rules, each with a test. The security model is a written, frozen document; every rule names its test.
Local first. Task titles, descriptions and comments never reach Satin’s servers.
One site at a time. No site access at install. You switch it on per site; removing access turns it off.
Tokens stay in the worker. Sign-in tokens live only in the service worker, encrypted at rest. Pages never see them.
Plain text only. Everything is shown as text in a closed shadow root. No remote code, no eval.
Signed, flags-only configuration. Remote configuration is signed with Satin’s key and can only switch reviewed behaviour off or on.
No extension telemetry, for now. The extension sends no usage statistics in this phase, and its diagnostics stay on your computer. The website counts page visits without cookies (see Privacy).
Token custody
Your sign-in never touches the page. And never rests on our servers.
Jira Cloud sign-in needs a secret that can’t live in an extension. A small stateless relay adds it, then returns tokens straight to your browser. Linear signs in by itself.
- The refresh token is encrypted with a non-exportable key.
- Each connection reaches one Jira site, identified by Atlassian.
- Tokens are sent only to Atlassian’s API and the relay.
- Disconnecting deletes the sign-in from your computer.
Who holds the keys
The Jira pageUntrusted
Can’t message Satin at all
Content scriptPartly trusted
Holds no credentials and no stored data
Service workerTrusted
Holds sign-in tokens, encrypted
Token relayMinimal
Adds Satin’s secret, keeps nothing
AtlassianThe provider
Issues tokens, serves your tasks
Dropped. Every message is checked against a schema and its sender. The page gets nothing back.
Proved by sender.test.ts, messages.test.ts
Plain-text rendering
Nothing in your tasks can run code. Not markup, not scripts, not instructions aimed at an AI.
Satin treats all task content as untrusted data and shows it as text under a strict content security policy: no remote code, no eval, no new Function.
- A title containing markup creates no element on the page.
- Instructions hidden in a description change nothing Satin offers.
- The content script reads only the page address.
What Satin shows
- elements created
- 0
- scripts run
- 0
- actions, as for any task
- 3
Shown as text, nothing more. Content is data: it can’t add a button or trigger an action.
The threat model, in brief. Its threats are written down with the specification, not after it.
T1
Hostile page scripts
A page sends forged messages to the extension.
Every message is checked for sender and schema. Satin’s view is isolated in a closed shadow root.
T2
Token theft
A page or content script tries to read sign-in tokens.
Tokens stay in the service worker. Content scripts receive data, never credentials.
T3
Scripts in content
A task title contains markup or a script.
Everything is rendered as escaped text. No raw HTML, ever.
T4
Prompt injection
A description tells an AI to reassign work.
Content is data. Any AI output is a validated proposal, and confirmations still apply.
T5
Tampered configuration
Someone alters the kill-switch file.
Signed with a pinned public key. Flags only, never code or new behaviour.
T6
Supply chain
A dependency is compromised.
One lockfile, pinned versions, few dependencies, and none younger than seven days.
T7
Wrong workspace
An action lands in another site or tenant.
The workspace is part of every task reference and is checked on every read-back.
T8
Vendor misuse
An SDK integration skips permission checks.
Conformance tests include permission-denied cases. The SDK holds no authorisation logic.
What we can’t promise. Residual risks, stated plainly.
The relay is a public door for Satin’s secret.
Anyone holding a valid code or refresh token for Satin could redeem it through the relay, as with any public sign-in client. So it checks the origin and callback address, limits requests and stores nothing.
A content script shares the page’s process.
A compromised page process could act as the content script, getting only that site’s tasks through the worker, and no tokens.
Encryption at rest is not protection from malware.
Malware running as you can use your browser as you do. Satin can’t defend against a compromised computer.
Where things stand.
In developmentSatin is pre-launch. Security testing, plus access-control and tenancy tests, must pass before any paid launch.
PlannedA security contact, a privacy policy and a plan for incidents will be published on this site before launch.
PlannedThe hosted relay will run on TLS 1.2 or later, with its secret held in the host’s encrypted store.
Satin holds no security or compliance certifications today. When that changes, this page will say so, with the evidence.
Questions, answered plainly.
Satin’s servers can’t. Your tasks travel from the app’s API to the extension in your browser, are shown there, and are cached briefly on your device. The cache is cleared when you disconnect.