01
Google-only website login
Production web access uses Google OAuth. Desktop password setup happens after the trusted web session exists.
Security
Designed around signed requests and outbound desktop execution.
Link Peeler avoids fragile inbound desktop access. Web handles identity and relay contracts while the desktop pulls work, signs requests, and stores local device state.
02
HMAC external API
API requests are signed and checked with nonce replay protection before work reaches the platform queue.
03
Idempotent queueing
Repeated client requests can safely replay known results instead of duplicating task side effects.
04
Outbound desktop polling
The desktop asks the cloud for work. The public relay does not need to call into a user's machine.
05
Quota gates
Membership controls offer limits and Pro-only integration surfaces before expensive work starts.
06
Device state
Refresh tokens, device keys, and runtime metadata stay anchored to the account and device chain.
Security control room
Every risky boundary gets a named control.
Security is part of the operating model: public identity, signed external entry, replay control, outbound desktop execution, quota gates, and audit state all have separate jobs.
trusted web identity
Website access starts with Google login.
Production website sessions are anchored by Google OAuth. Desktop password setup is downstream of that trusted account session.
control 01 public account before local credential.
oauth.google -> session.issued
desktop.password -> created_after_trust
Public web Login, registration, account pages, billing, and downloads live behind website sessions and private account routes.
identity boundaryExternal API Signed API Links validate timestamp, nonce, idempotency, quota, and payload before creating work.
request boundaryCloud relay The relay stores explicit task state and lets a linked desktop pull work outbound instead of accepting inbound calls.
queue boundaryDesktop device Local resolution, refresh tokens, device keys, browser context, and runtime cache stay device scoped.
runtime boundaryTrust model
Security controls are attached to the workflow, not bolted on after launch.
Link Peeler separates public identity, device credentials, external API signing, replay protection, idempotent queueing, and quota gates so each sensitive boundary has a specific control.
Identity
Website sessions are anchored by Google login in production.
Device
Desktop credentials and device keys stay local to the user machine.
API
External scripts use signed requests instead of unauthenticated webhooks.
Replay
Nonce and idempotency records block duplicate side effects.
Quota
Plan limits are checked before expensive work starts.
Control matrix
What each security control prevents.
The security model is written as operational controls, not abstract promises. Each control names the risk it blocks and the evidence operators can inspect.
Prevents unauthenticated public account creation from becoming a trusted desktop runtime credential.
Prevents unsigned webhooks and replayed requests from creating new link-fetch tasks.
Prevents duplicate side effects and blocks expensive production work before entitlement checks pass.
Prevents the cloud from needing inbound access to a user's machine while keeping local context intact.
Security FAQ
Security questions before connecting scripts.
Are external API calls signed?
Yes. API calls use HMAC signing with nonce checks so replayed requests can be rejected before they create work.
Does the cloud call directly into the desktop?
No. The desktop pulls queued work outbound, which avoids requiring an inbound public tunnel for task execution.
Why does the website use Google-only login in production?
Google login anchors the public account. A separate desktop password is created only after the web account is trusted.
How are duplicate requests handled?
Idempotency keys allow known request replays to return a previous result instead of creating duplicate queue entries.