Current public-site scope
This website is a static-first Next.js application with public content, local images, a deterministic in-browser text demo, generated discovery files, and a configured email handoff. It has no account, authentication, database, upload, API submission, payment, cookie, analytics, or customer dashboard in the current code.
Current website controls
The current application configures or enforces:
- same-origin resource and connection rules through a Content Security Policy;
- framing denial, MIME-sniffing protection, and a restrictive referrer policy;
- disabled browser access to camera, microphone, and geolocation;
- validated public origins and contact configuration for production builds;
- encoded email subject and body values rather than a web submission endpoint;
- escaped React text rendering and bounded browser-demo input.
These controls reduce the current static-site attack surface. They are not a security certification and do not cover the owner's final hosting layer.
Report a suspected vulnerability
Use the contact route and identify the message as a security report. Describe the affected public URL or component, the observed behavior, the practical impact, and a safe way to reproduce it. Do not send credentials, private records, live exploit payloads containing personal data, or confidential customer material.
The public contact route is not an emergency or managed incident-response service. No acknowledgement or resolution time is promised.
Safe testing boundary
Keep any investigation non-destructive and limited to the public website:
- do not access, change, retain, or disclose another person's data;
- do not disrupt availability or use denial-of-service techniques;
- do not use social engineering, phishing, malware, or physical intrusion;
- do not run high-volume automated scans against production infrastructure;
- do not bypass a third party's controls or test a customer or provider;
- stop if testing could expose sensitive information or affect another person.
This guidance does not promise a bounty, safe harbor, immunity, public credit, or permission beyond applicable law and the narrow public-site scope above.
What makes a report useful
- Name the public route, asset, or component affected.
- Explain the security impact in plain language.
- Provide the smallest safe set of reproduction steps.
- Remove personal data, secrets, and unrelated system information.
- Share a preferred way to ask follow-up questions, if appropriate.
Screenshots or proof-of-concept material should be redacted and limited to what is necessary to understand the issue.
How reports should be handled
A report should be assessed against the current code and deployment, reproduced safely, prioritized by credible impact, and fixed without exposing reporter or user information. Public disclosure should wait until the owner has assessed the issue and a safe resolution exists.
The site does not publish a guaranteed triage process, response window, bounty, or disclosure timetable. Any future managed program must replace this general route with its approved scope and commitments.
Outside scope and urgent situations
Telephony, ASR, call recording, customer data, business integrations, accounts, and operational incident response fall outside this public-site security scope. A concern involving one of those systems must go to its confirmed owner or provider through an approved channel.
For an immediate threat to life, safety, or an active local emergency, contact the appropriate local emergency service. Do not use this website's general contact route for urgent response.