The current Ptichi website is a public information and practice site. It has no user accounts, checkout, voice upload or microphone capture. That narrows the attack surface; it does not make the site magically immune to security defects.
Security boundary of the current Ptichi site
What the current Ptichi website exposes, what it does not handle, and how to report a security concern without inventing a private channel.
Current public surface
The site serves public pages, static assets, public JSON/data resources and a small amount of browser-side interaction such as analytics consent and text-only rehearsal helpers. The website boundary is described separately on the privacy page.
Do not enter passwords, confidential client material, private recordings or other secrets into Ptichi pages. The site is not a secure document exchange channel.
What counts as a security issue
Examples include:
- a script or dependency loading from an unexpected origin;
- a page exposing information that was intended to remain private;
- an injection or browser behavior that can alter what another reader sees or does;
- a permissions or policy regression that makes the site request capabilities it should not need;
- a deployment/configuration error that creates a meaningful security boundary change.
A typo, broken link or factual error normally belongs under Corrections, not security.
Reporting boundary
Ptichi does not currently publish a private vulnerability-reporting inbox or encrypted submission channel. The contact page is the canonical statement of current contact availability.
Do not publish sensitive exploit details or private data merely because no private channel is available. A missing reporting channel is a limitation to document, not permission to expose someone else's information.
If a private security route is added later, it should be published here before the Agent-Ready Web Profile advertises it as a stronger reporting capability.
No security badge by metadata
A security page, HTTPS, policy header or green automated check is not a security certification. Repository tests can catch known regressions; they do not prove the absence of vulnerabilities in the deployed service or its providers.
