Security & trust model

Lynx PDF Studio processes documents locally, and treats a workflow file (*.opw.yaml) as potentially untrusted — it may be cloned from a repo, shared by a colleague, or authored by a coding agent. The engine is built so that a crafted workflow cannot quietly reach outside its own project. This page states exactly what is protected and what is not, so you can make an informed decision before installing — or before rendering a workflow you did not write.

When data leaves your machine

By default: never. Documents are processed on your machine and there is no server of ours. Every network path that exists is listed below, with the exact thing that gates it.

Path	What is sent, where	What gates it
Remote OCR offload	Pages sent for OCR to a GPU machine you own, over key-based SSH.	Off by default. Requires the `pdfStudio.allowRemoteRender` setting and a host you configure.
AI operations (summarize, translate, semantic_search)	Extracted document text sent to the model provider you configure — a local Ollama by default; a cloud provider only if you set an API key.	Only runs if the workflow contains the operation. Cloud use additionally gated by `pdfStudio.allowAiRequests` and your own API key.
url_to_pdf / html_to_pdf	Fetches the URL (and any resources the HTML references) that the workflow names.	Only runs if the workflow contains the operation. Review workflows you didn't write — see the residual-risks note on SSRF below.
Extension telemetry	Anonymous feature-usage events (feature and operation names, no paths, no content, no PII) to Google Analytics.	On by default; disable with `pdfStudio.telemetry.enabled` — and VS Code's global telemetry setting silences it too.
This website	See About this website below.	—

What never exists: an account, an upload service, or a copy of your documents on any infrastructure of ours. Your coding agent, if you use one, never processes the PDF either — it only writes the workflow file.

What is protected

Path traversal. Every input, output, asset, and extract/convert path is confined to the workflow directory. .., absolute paths, Windows drive-relative/drive-absolute and UNC paths are rejected — both as a fail-fast validation error and again at read/write time. A workflow cannot read ~/.ssh/id_rsa or write into a Startup folder or .git/hooks.
Environment secrets. ${ENV_VAR} substitution only applies to password params. A ${VAR} in any other param — text, a title, a URL, a path — is left literal, so a workflow cannot read arbitrary host environment variables into an output PDF or a URL.
Interpreter/binary pinning. The optional Python backend is pinned to its absolute executable path and the setting is machine-scoped, so a workspace cannot point the interpreter at a planted binary. The system browser is resolved from its known install location before any name-based PATH lookup.
Webviews. The preview and panels use a strict nonce CSP and load no remote resources.
Creator-op guards. Markdown/HTML→PDF operations must run first with a matching input, so a working PDF can't be misinterpreted as source.
Page bounds. Page numbers are validated as 1-based for every operation, so a zero or negative index can't silently edit the wrong page.

Residual risks — know these before rendering an untrusted workflow

These follow from what the features intrinsically do; they are documented rather than blocked.

url_to_pdf / html_to_pdf fetch network and local resources by design. A workflow can name any URL, and rendered HTML can reference remote resources. This is an SSRF vector: rendering an untrusted workflow can cause outbound requests from your machine. Don't render untrusted URL/HTML workflows on a host with sensitive internal network access.
The headless browser runs without a sandbox. High-fidelity Markdown/HTML rendering drives your system Chrome/Edge with --no-sandbox against workflow-controlled content. Treat rendering untrusted HTML like opening it in a browser.
Confinement is lexical, not physical. A symlink inside the workflow directory that points outside it can still redirect a read/write. Don't render untrusted workflows in a directory that contains symlinks to sensitive locations.
Sidecar working directory (Windows). The Python sidecar runs with its working directory set to the workflow folder so relative asset paths resolve; the browser is resolved by absolute path first to reduce same-name binary risks.

Recommendation: the .opw.yaml is code. Review a workflow you didn't author before rendering it — the same way you'd review a script — and be especially cautious with url_to_pdf / html_to_pdf and with directories that contain symlinks.

About this website

This site is static files on GitHub Pages. It sets no cookies and shows no consent banner because there is nothing to consent to store. If enabled, it counts page views anonymously with Google Analytics in cookieless mode: every consent signal is denied, so each page view sends a single cookieless ping to Google — which, per Google's documentation, may include IP address and user agent in transit, and which Google states it does not store or log. No advertising, no remarketing, nothing tied to your identity. The only third party this site may contact is Google Analytics.

Reporting a vulnerability

Contact info@lynxdi.com.