Design notePreview

Thumbnails without trust — designing IDOP 1.1

Why the IDOP 1.1 thumbnail is PNG only, one size, passive, never a reason to refuse a package, and never drawn where it could pass for the reader's interface.

IDOP LABS2 min read

File formatsSecure execution

A picture of a document, shown in a file list or a link preview, sounds like the least controversial feature a format could add. For IDOP it raised four questions worth writing down.

A thumbnail is self-declared

Whoever produced the file chose the picture. It can show content the document does not contain, or an image designed to look like a permission prompt. The IDOP 1.1 draft therefore treats the thumbnail like the rest of a document’s application metadata: a reader must not present it as a verified rendering, and must not draw it where it could be mistaken for its own controls.

Showing it must cost nothing

The point of a thumbnail is to show something without opening the document. So showing it must not run any of the document’s code and must not cause any network request. The thumbnail lives under _idop/, outside code/, and is never exposed to the document through the Runtime API.

One decoder, bounded

Image decoders have a long history of memory-safety bugs, and a thumbnail is decoded before the user has chosen to open anything. The draft allows PNG only, between 16 and 1024 pixels per side, at most 256 KiB, not animated. WebP and AVIF would make files smaller, at the cost of another decoder running on untrusted input. We decided the saving was not worth it; a later minor version can revisit that if real packages show otherwise.

We also decided against a second, smaller size: scaling one image down is cheap, and two images double what a producer must keep current.

Never a reason to refuse

Everything else in IDOP is strict — a package that breaks a rule is refused. The thumbnail is the exception, deliberately. It is optional and passive, so a malformed one is ignored and reported as a warning (IDOP-THUMB-001), and the package is processed as if it were absent. A thumbnail in a package that still declares 1.0 is ignored as 1.0 requires, with its own warning (IDOP-THUMB-002).

Staleness, honestly

A thumbnail can show an older state than the one saved. The draft lets a reader keep, refresh or remove it on save, and recommends removing one it cannot refresh after a substantial change. We kept that a recommendation rather than a requirement: only the reader knows whether a change makes the picture misleading, and a rule that depends on that judgement could not be tested.

The reference core already implements these checks; reader support is in progress.