Security & vulnerability reporting
A responsible channel for reporting security problems affecting a kookey installation.
1.Current service boundary
kookey currently offers a static presentation website. It does not provide hosted accounts, room storage, private messages, payments, or the planned social-service backend. The production host and its security configuration have not been verified. No security audit, certification, or hosted-service incident-response capability is confirmed. A future hosted service will have a separate security scope and operator.
2.Report privately
No dedicated security address or coordinated disclosure process is confirmed for the hosted service. The site lists contact@kookey.me for project inquiries, but monitoring is not verified; do not treat it as a dependable emergency or vulnerability channel. A monitored security contact and safe submission instructions are not available yet. We’ll publish them before accounts open. If you choose to contact the project before that route exists, do not include passwords, access tokens, exploit payloads that expose other users, or personal data.
3.What to include in a report
When a private reporting route is available, we’ll explain what to include: the affected site or release, the issue, its possible impact, and safe steps to reproduce it. Include the browser or tool version only when relevant. Stop testing as soon as you confirm the issue; do not change or delete data, disrupt service, persist access, or test beyond the authorized scope.
4.Safe testing and public disclosure
There is no security reporting route or authorized testing program yet. Do not scan, access accounts, bypass controls, or test a production system without explicit permission. We’ll share how to report a security issue and what testing is allowed before the hosted service opens.
5.Response expectations
No acknowledgment target, response deadline, or security contact owner has been established. The future process will state how a report is acknowledged, how the reporter receives updates, how severity is assessed, and how public disclosure is coordinated after a fix or an agreed period. Until a monitored channel and schedule are published, no response or resolution time is promised.
6.Security practices and operator responsibilities
The hosted service’s security controls for its app, hosting, media, backups, logs, and incident response have not been published yet. We’ll share them before launch. Self-hosting is not available yet; a future setup guide will explain what running an instance involves. No web service can promise absolute security.