Developers · Security
The security model: assume the file is hostile.
IDOP documents contain code written by someone else. The format is designed around that fact. This page summarises the model; sections 9, 12 and 17 of the specification are normative.
§ 01Overview
Three layers, each sufficient on its own terms.
Input
.idop file
Untrusted until proven otherwise.
Step 1 · Reader
Validation before execution
- Size limits
- ZIP structure, parsed independently
- mimetype
- Every path
- Bounded decompression, CRC
- Manifest
- Executable boundary
- Capabilities and consent
Any failure refuses the whole file, with a stable error code. Nothing runs before all checks pass.
Step 2 · Running
Sandbox
The document’s code. Opaque origin, no network, no access to the reader or other documents.
code/**Reader
Answers each request — or refuses it.
- Storage — a working copy of
storage/ - Network — only declared origins, after consent
- Credentials — injected by the reader, never shown to code
Step 3 · Save
A new revision
Only storage/ and the revision in idop.json change. The result is validated again before it replaces the file.
§ 02Threats and mitigations
What the design defends against.
A summary of the threat model. It is not a guarantee: implementations can have defects, and we treat reports of them seriously.
| Threat | Example | Mitigation |
|---|---|---|
| Malformed or hostile archives | ZIP bombs, overlapping entries, polyglot files, path traversal | Independent ZIP parsing, strict profile, bounded decompression, CRC checks; any violation refuses the file |
| Code that escapes the document | Access to the reader, other documents, cookies or storage | Opaque-origin sandbox without allow-same-origin; one channel per session |
| Silent data exfiltration | Sending what the user enters to a server | No network by default; declared exact origins and methods; user consent; no redirects |
| Credential theft | Reading or forwarding API keys | Keys held by the reader, injected after all checks, pinned to user-chosen origins, never shown to code |
| Runaway costs | An approved document calling a paid API in a loop | A finite request budget per session, plus size, time and concurrency limits |
| Changed code after approval | A document updated to do more than was approved | “Allow for this version” is keyed to a digest of all code and capability declarations |
| Spoofing | A document pretending to be the reader’s interface | Metadata and thumbnails are self-declared and never drawn as the reader’s own controls |
§ 03Principles
Rules the design does not bend.
No best-effort mode
A reader must not run a package that failed validation, and must not run part of one. There is no “open anyway”.
Static checks are not the boundary
The executable-boundary checks reject inline scripts, remote URLs and dynamic evaluation, but they are defence in depth. The sandbox is the boundary, and a reader must enforce it regardless.
The manifest can narrow, never widen
A credential’s allowed origins are set by the user, not the document. A manifest can only restrict where a credential is used.
Consent is specific
The prompt states which credential would travel to which origins and for what declared purpose. Approval is invalidated by any change to the code or to the declared capabilities.
Nothing is written without the user
There is no autosave into the package. Each save is a new revision, fully validated before it replaces the file.
§ 04Limits of the model
What IDOP does not promise.
- Authorship is not verified in 1.0. Titles, authors and icons are self-declared. Publisher signatures are reserved in the format and under research.
- Content can still mislead. A document can display anything, including false information. Open documents from people you trust.
- Granted access is real access. If you allow a document to reach a service with your key, the document can use that service within the declared limits.
- Shared files are copies. Anyone who can open a document can keep it. Read-only sharing is not copy protection.
Found a weakness? Write to security@idoplabs.com — see our disclosure policy.
Security questions?
We would rather hear about a problem than not. Reports are acknowledged and handled privately until fixed.