Security
How to report a vulnerability, and what's actually in scope for a site with no server-side accounts.
Report a vulnerability
Email admin@projectresearchllc.com with a description and, if you can, steps to reproduce. We read every report and aim to acknowledge within a few business days. This is a small, self-funded beta — please be patient with response times.
A machine-readable copy of this contact lives at /.well-known/security.txt, per RFC 9116.
Safe harbor
If you make a good-faith effort to test within the scope below, avoid privacy violations and service disruption, and report what you find to us before disclosing it publicly, we will not pursue legal action against you for that research.
What's in scope
- This website (www.jackdawbook.com) and its client-side code: HTML, CSS, and the JavaScript in
assets/. - Cross-site scripting, content-security-policy bypasses, clickjacking, and other issues that would let one visitor's browser session affect another's.
- Flaws in the encryption scheme used for passcode-protected books (AES-256-GCM, PBKDF2-SHA256 key derivation).
- The mobile apps, once they ship — for now they don't exist yet, so there's nothing there to test.
What's out of scope, and why
Jackdaw Book has no user accounts, no login, and no database — there is no server anywhere that holds the names you save. That changes which categories of bug can exist here at all:
- SQL injection. There is no SQL database. Every book lives in the browser's own
localStorage, read and written directly by JavaScript — there is no query layer to inject into. - Credential stuffing. There are no accounts or passwords to stuff. The optional "passcode" on a book is a local encryption key, checked entirely on-device; it is never sent anywhere, so it cannot be attacked over the network by trying leaked passwords.
- Server-side row-level access control. There are no rows and no server-side sessions. The one access boundary that matters is the browser's own same-origin policy around
localStorage, which the browser enforces, not this site's code. - Denial of service and volumetric attacks against our infrastructure — this is a static site behind normal hosting, and takedown attempts don't reveal or expose any user data even if they succeeded.
If you believe you've found a way around one of these architectural guarantees — for example, a way for this site's own script to leak a book's contents off-device, or a way for a crafted backup file to run script when imported — that is very much in scope and we want to hear about it.
How the data itself is protected
Full detail is in the white paper and the privacy policy. In short: everything you save stays in your browser's storage unless you export a backup file yourself. Set a passcode and the whole book is encrypted with AES-256-GCM before it touches storage, with the key derived from your passcode via PBKDF2-SHA256. The passcode itself is never stored, so it can't be recovered — by you, by us, or by anyone else.
AI-assisted development
Parts of this site, including this page, were drafted with AI assistance and reviewed by a person before publication, as described in our AI governance policy.