Security

Found something? Report it privately, and thank you — it is genuinely appreciated.

Reporting a vulnerability

Use the feedback form and pick the topic “A security problem”.

That form is a private channel. It does not post anything on the web: submissions go straight into this project’s issue tracker, which is closed — only the maintainer can read it. There is no public repository, no public issue list, and no other place a report could surface before a fix exists. Nothing you write is published anywhere.

Leave a way to reach you if you want a reply — an email address, or a Discord, LinkedIn or GitHub handle; the form asks which. The field is optional, and without it a report is genuinely anonymous, which also means there is no way to come back to you with questions or to credit you.

A useful report says what you did, what happened, and why it matters. A proof of concept helps enormously. Report it even if you are not sure it is exploitable — deciding that is the maintainer’s job, not yours.

One limitation, stated plainly: the form is protected by HTTPS in transit, but there is no end-to-end encrypted intake and no PGP key. If a finding is severe enough that you want an encrypted channel before describing it, send a short note with no details and ask for one.

What to expect

• Acknowledgement within a few days. This is a small project run by one person, not a company with an on-call rota — but reports are read and answered.
• An honest assessment. If it is a real issue you will be told so, along with the intended fix and a rough timeline. If it is not, you will be told why.
• Credit, unless you would rather not have it. The release notes will name you if you want to be named, and leave you out if you do not.
• Coordinated disclosure. Details go into the release notes once a fixed release is out. If a fix is taking a long time, that is a conversation, not a wall of silence.

Safe harbour

Research conducted in good faith under this policy is welcome, and no legal action will be pursued over it. That means: test against your own installation, do not access other people’s data, do not degrade the service for anyone else, and give a reasonable chance to fix before publishing.

Out of scope: denial of service, social engineering, physical attacks, spam, and reports generated by a scanner with no analysis behind them. Findings against this website and against the app are both in scope.

What the design already rules out

Worth knowing before you dig, because it removes whole categories of bug from the equation:

• There is no account, no session and no cookie — so no authentication bypass, no session fixation, no CSRF against a logged-in user.
• There is no server-side rendering and no database. Every page is a static file. The only endpoint that accepts input is the feedback form.
• The editor sends nothing about you or your diagrams. They stay on your machine; the editor itself has no upload path to attack. The one place this site takes a file is the feedback form, and only a .zip you pick by hand: it is bounded in size, never unpacked or inspected on the way through, and stored under a name this site generates — nothing from the uploader reaches a path. The one thing the editor asks for is itself: now and then it checks this site for a newer version of its own code, which is what puts the “Update available” prompt on screen — same origin, no third party, no identifier — and the new version is only applied when you click Reload. The desktop build’s update check is the same shape against this site’s release feed: notify-only, and the automatic check is off until you turn it on. See privacy.
• The pages ship a strict Content-Security-Policy with no unsafe-inline and no unsafe-eval, and load nothing from a third-party origin — with one exception, the Ko-fi tip panel on donate, which is not requested at all until you press the button.

None of that makes the project immune, and a finding that contradicts any of the above is exactly the kind of thing worth reporting.

security.txt

This policy is advertised in machine-readable form at /.well-known/security.txt, per RFC 9116.