Please report privately, not in a public issue.

• Preferred: GitHub's private vulnerability reporting on this repository (Security tab, then "Report a vulnerability"). It gives us a private thread and an advisory draft in one place.
• Alternative: email rydersel@protonmail.com with "Candela security" in the subject.

A useful report says what an attacker can do, and how you established it. If you have a proof of concept, include it; if reproducing it needs a particular monitor, cable or macOS version, say which, because the hardware in the development setup is a short list and we may need to ask you to confirm a fix.

The latest release. Fixes ship in a new release rather than as patches to an older one, and the in-app updater brings every install forward.

In scope:

• The app itself. Candela runs unsandboxed and holds two optional macOS permissions: Accessibility (only for driving external displays from the media keys) and Screen Recording (only when you opt into measured exposure sampling). Anything that escalates from those, or that makes the app act on data it should not, is in scope.
• The update path. Updates are delivered by Sparkle from a signed appcast, and every archive is verified against an EdDSA public key baked into the build. Anything that lets an unsigned or substituted archive install, or that downgrades an install to an older build, is in scope.
• The release artifacts. The notarized, Developer ID signed build and the appcast that points at it.
• The recorded data. Exposure history, panel hours, checkup reports and the diagnostics report are local files. Anything that causes one of them to leave the machine, or that puts more in one of them than it is documented to carry, is in scope. The diagnostics report is written to be pasted into a public issue and deliberately excludes serial numbers.

Out of scope:

• Anything requiring an attacker who is already running code as your user.
• Behaviour of monitors themselves, and of undocumented macOS interfaces, on a macOS version we can reproduce nothing on. Report those as ordinary issues.
• Reports generated by automated scanners with no demonstrated impact.

This is a small project, so the timeline is stated as what we will do rather than as a service level:

• We aim to acknowledge a report within 7 days.
• We aim to have an assessment, and either a fix or a plan, within 30 days.
• A fix ships in the next release, and the advisory is published when that release is out, crediting you unless you ask otherwise.
• If a report goes unanswered for 30 days, you are free to disclose publicly.

Please give us a chance to ship a fix before publishing. If a vulnerability is already being exploited, say so and we will treat the timeline as void.