Security Disclosure Policy
Good-faith security research on Dodecave is welcome, appreciated, and authorized under the safe-harbor terms below.
Report findings to [email protected]. Acknowledgment
within 48 hours, triage within 7 days, resolution or a written
explanation within 90 days.
Reporting a vulnerability
Please include, where applicable:
- A clear description of the vulnerability and its impact
- Steps to reproduce, ideally a minimal proof-of-concept
- The affected URL, file, endpoint, or commit hash
- Any other context that helps us reproduce and fix
If the issue is sensitive enough that you'd prefer encrypted communication, say so in your initial email and we'll arrange a channel.
What to expect
- Within 48 hours: acknowledgment of your report
- Within 7 days: triage decision (severity, scope, accepted or declined with reasoning)
- Within 90 days: resolution shipped, or a written explanation if we cannot fix within that window
We will keep you updated throughout. If you want public credit, we'll honor it in the commit history and in the Hall of Fame below once the fix has shipped.
Scope
In scope
dodecave.comandwww.dodecave.com, the public PWA and APIs- The Progressive Web App served from those origins
- Backend services reached via the public API
(
/api/ai-report), cookie-gated
Out of scope
- Internal, operator-only infrastructure not reachable from the public internet
- Administrative surfaces, which are not publicly reachable; reaching one from outside authorized operator access would be a finding, activity from within it is not
- Automated scanner output without a demonstrated exploit
- Issues requiring physical access to the operator's devices
- Volumetric denial of service (report L7 logic-flaw DoS, not floods)
- Social engineering of the operator or users
- Findings in third-party dependencies (CDN, model providers, git hosting): report those upstream
- Email spoofing absent a demonstrated bypass of the operator domains' published SPF/DKIM/DMARC records
Safe harbor
If you make a good-faith effort to comply with this policy during your research, we consider that research authorized access for purposes of the federal Computer Fraud and Abuse Act (18 U.S.C. § 1030), the Texas Breach of Computer Security statute (Tex. Penal Code § 33.02), and any anti-circumvention claim under the DMCA (17 U.S.C. § 1201); and:
- Provided your activity stays within this policy and is conducted in good faith, we will not initiate or recommend civil or criminal action against you, and will not report your activity to law enforcement
- We will work with you to understand and resolve the issue quickly
- If a third party initiates legal action against you and we are made aware, we will take reasonable steps to make it known that your actions were conducted under this policy
This authorization is limited to the in-scope systems above and does not authorize access to other users' data or to systems we do not own. This policy is a statement of how we handle good-faith reports; it is not an offer, contract, or guarantee of payment, and participating in it creates no contractual relationship.
Good faith requires that you:
- Do not access, modify, or destroy data beyond what is strictly necessary to demonstrate the vulnerability
- Do not degrade the service for other users
- Do not publicly disclose before we've had a reasonable chance to fix (coordinated disclosure, usually 90 days from initial report)
- Do not access, store, or exfiltrate other users' personal data; if you encounter personal data, stop, do not save it, and tell us in your report
- Comply with all applicable laws
What we do with reports
- Every report is logged with an internal tracking ID
- Sensitive details stay between you and the operator until resolved
- After fixing, the commit history describes what was fixed and why, with attribution to you if you want it
- No paid bug bounty at this time: recognition and genuine thanks. If a finding is serious enough that compensation feels warranted, mention it in your report and we'll discuss.
Hall of Fame
Researchers who responsibly disclose issues are listed here.
Render provenance: verify a Dodecave file yourself
Every audio-visual render Dodecave distributes carries a cryptographic provenance signature over its media essence (the actual frames and audio, not just the metadata). Anyone can verify, no account, no contact with us, and no secret required:
- What it proves: the file was produced by Dodecave and has not been re-encoded or re-cut since we signed it. A recompressed or altered copy fails verification.
- Public key:
https://dodecave.com/.well-known/dodecave-provenance-mldsa.pub(post-quantum signature scheme, FIPS 204). - Verifier:
scripts/verify-provenance.pyin the published tooling; usage:python3 verify-provenance.py the-file.mp4→✓ VERIFIEDor an explicit mismatch. Requires only Python,dilithium-py, andffmpeg.
Canonical locations
- This page:
https://dodecave.com/security.html - Machine-discoverable:
https://dodecave.com/.well-known/security.txt(per RFC 9116) - Provenance public key:
https://dodecave.com/.well-known/dodecave-provenance-mldsa.pub