Vulnerability Disclosure Policy

1. Reporting a Vulnerability

Send vulnerability reports to security@talkingpaper.app. The same address is published in our RFC 9116 .well-known/security.txt file.

A useful report typically includes:

• A clear, reproducible description of the issue and its security impact.
• Step-by-step instructions, proof-of-concept request / response, screenshots or video where helpful.
• The affected URL, endpoint, parameter, or component, and the date and time of the test (with time-zone).
• The account or test identifiers you used, so we can correlate to our logs.

Please report in English. We accept encrypted email only when a PGP public key is published; until then, send reports in plain text and avoid including sensitive third-party data in the body.

2. Scope

This policy covers the production Talking Paper service and its first-party assets:

• talkingpaper.app and its subdomains.
• The Talking Paper mobile application (when published).
• First-party APIs documented under /api/.

3. Out of Scope

The following are out of scope under this policy. Reports limited to these classes are unlikely to be actionable:

• Social-engineering attacks against our staff, contractors, or users (phishing, pretexting, vishing).
• Physical attacks against our offices, infrastructure, or personnel.
• Issues in third-party processors (for example our hosting, payment, email, or AI providers). Please report those directly to the vendor; our subprocessor list is published at /legal/subprocessors/.
• Denial-of-service or load testing without prior written arrangement, including volumetric, application-layer, or rate-limit-exhaustion testing.
• Automated scanner output without demonstrated security impact (we cannot triage raw tool dumps).
• Best-practice findings without an exploit path (missing HTTP headers, TLS-cipher preferences, banner / version disclosure, autocomplete attributes, weak Captchas in isolation).
• Issues that require access to a victim's already-compromised device, browser, or account.

4. Safe Harbor

We will not pursue legal action against, or support legal action by third parties against, security researchers whose research and disclosure complies with this policy in good faith. Specifically, when you act in good faith we will treat your activity as authorised under:

• The U.S. Computer Fraud and Abuse Act (CFAA) and corresponding state computer-misuse laws.
• The U.K. Computer Misuse Act 1990.
• Equivalent computer-misuse and unauthorised-access statutes in other jurisdictions.
• The anti-circumvention provisions of the U.S. DMCA (we will not bring a claim against you for circumvention undertaken solely for the purpose of researching or reporting a vulnerability covered by this policy).

Acting in good faith for the purposes of this policy means:

• You stay within the in-scope assets defined in section 2 and avoid the conduct listed in section 3.
• You make a good-faith effort to avoid privacy violations, service degradation, and data destruction.
• You only interact with accounts you own or are authorised to test (do not target real user data).
• You stop testing and notify us as soon as you identify a vulnerability or encounter sensitive data, and you do not exfiltrate more data than necessary to demonstrate the issue.
• You give us a reasonable opportunity (see section 5) to investigate and remediate before any public disclosure or third-party disclosure, and you coordinate disclosure with us.

This policy does not authorise activity that violates the rights of any user or third party, including unauthorised access to other users' accounts or data. It also does not bind any third party (for example, our subprocessors). If in doubt about whether a particular test is in scope, ask us first at security@talkingpaper.app.

5. Response SLA

Our target response and remediation timeframes are:

• Acknowledgement: within 5 business days of receipt.
• Triage and severity decision: within 10 business days.
• Remediation: critical issues within 90 days of triage; lower-severity issues on a best-effort basis prioritised against operational risk.
• Coordinated disclosure: by mutual agreement, typically after a fix is deployed and any necessary customer communication has gone out.

If we are unable to meet a target we will tell you and explain why. Researchers who follow this policy are credited in our remediation notes where they wish to be named.

6. Rewards

We deeply appreciate disclosure but we do not currently operate a paid bug-bounty programme. Reports that meaningfully improve our security may be acknowledged publicly (with your permission) and credited in remediation notes. If we launch a paid programme in future, the terms will be published on this page and announced in advance.

7. Changes to this Policy

We may update this policy from time to time. Material changes are versioned alongside our other legal documents; the current version is shown above. The Expires field in .well-known/security.txt is refreshed when this policy is reviewed.