If you discover a security issue in AethelReader, please do not file it as a public GitHub issue.

Email syntheye.help@gmail.com with:

1. The version of AethelReader (visible in Settings → About).
2. A description of the issue.
3. Steps to reproduce.
4. Your assessment of impact (e.g. local file disclosure, code execution, data leak).
5. Whether you've shared this with anyone else.

I'll acknowledge within 3 business days and keep you updated on the fix.

Only the latest released version receives security fixes. Older versions get a one-line "upgrade to current" response.

AethelReader is a local-first desktop application. Its threat model is bounded:

• It does not accept network input.
• It does not run a server.
• It does not have an account system or remote storage.
• It does not have an auto-updater.

The only outbound connections are to http://localhost:11434 (Ollama) and http://localhost:5273 (Foundry Local), both opt-in and both same-machine.

The realistic attack surfaces are:

• Document import parsing — a malicious PDF or EPUB could exploit a vulnerability in PDF.js or JSZip. Parsing happens in the WebView sandbox.
• WebView XSS — content from imported documents is rendered as text; if escaping breaks anywhere, it could allow JavaScript execution.
• Tauri command surface — currently only start_ollama_provider. It runs a known executable (ollama serve). It does not take untrusted input.
• localStorage — contains your library and reading progress. Anyone with local access to your user profile can read it (this is true of all browser localStorage).
• Quick Read hotkey — uses Web Speech API and getSelection(). If a future version adds anything that runs commands based on selected text, that surface needs review.

• Sandbox escapes from the underlying Chromium / WebView2 — please report those to Microsoft / the Chromium project, not here.
• Issues that require local administrator access already — at that point the attacker already owns the machine.
• Bugs that are functional issues, not security issues — those go in regular GitHub issues.

• Acknowledge: 3 business days.
• Fix critical issues: within 14 days, in a patch release.
• Fix non-critical issues: rolled into the next minor release.
• Public disclosure: coordinated with the reporter; default 90 days from acknowledgment, or sooner if a fix is shipped.