Binding Legal Safe Harbor · Coordinated Vulnerability Disclosure
RFC 9116 & ISO/IEC 29147 Aligned

Vulnerability Disclosure Policy

At PrivacyScrubber, security is rooted in verifiable client-side isolation. We value the vital contributions of independent cybersecurity researchers and are committed to clear, collaborative, and legally protected vulnerability remediation across all four execution surfaces.

< 24h
Triage SLA

Initial assessment & tracking ID

SLA: Direct Security Engineering Desk
Safe Harbor
Legal Protection

No legal action for good-faith research

Statutes: CFAA · DMCA § 1201 · EU 2013/40
4 Surfaces
Research Scope

Web, Extension, MCP Server & SDK

Scope: Client RAM · MV3 · Stdio · WASM
Hall of Fame
Public Recognition

Security advisories & researcher credits

Manifest: /.well-known/security.txt

1. Legal Safe Harbor Commitment

Formal legal authorization and statutory immunity for ethical security researchers.

If you conduct security research in good faith and in compliance with this policy, PrivacyScrubber binds itself to the following legal protections:

No Legal Action

We will not pursue civil claims or initiate criminal complaints under the Computer Fraud and Abuse Act (CFAA), DMCA § 1201 (anti-circumvention), or equivalent international cyber laws.

Immunity: Civil & Criminal Waiver
Explicit Authorization

We deem your good-faith testing across our local binaries, Web Workers, Chrome Extension, MCP Server, and SDK to constitute "authorized access" under applicable anti-hacking statutes.

Status: Pre-Authorized Research
Third-Party Intervention

If a third party (such as an infrastructure host or CDN provider) initiates legal action against you for research conducted strictly within this policy, we will formally affirm our authorization.

Defense: Written Safe Harbor Attestation
Statutes Covered: 18 U.S.C. § 1030 (CFAA) · 17 U.S.C. § 1201 (DMCA) · EU Directive 2013/40/EUCondition: Zero Real Customer Data Exfiltration · Prompt Reporting

2. Program Scope Matrix (4 Surfaces)

Qualifying security targets and non-qualifying operational activities.

In-Scope Targets & Vulnerabilities
  • Client-Side Data Exfiltration: Any vector that bypasses the zero-network policy or transmits unencrypted prompt text to an external host during active scrubbing.
  • DOM XSS & Token Dictionary Extraction: Cross-site scripting or prototype pollution vulnerabilities capable of extracting in-memory surrogate token dictionaries.
  • Cryptographic Faults: Implementation flaws in TEAMS Argon2id key derivation, XChaCha20-Poly1305 session vaults, Ed25519 signature verification, or hardware cryptographic entropy generation.
  • MCP Server & SDK Privilege Escalation: Local IPC/stdio socket leaks, path traversal, or memory corruption in @privacyscrubber/mcp-server or @privacyscrubber/sdk.
  • Regex Denial of Service (ReDoS): Pathological input patterns causing catastrophic backtracking or unbounded CPU locking inside Web Workers.
Scoring: CVSS v3.1 / v4.0 Base + EnvironmentalPriority: Zero-Egress & RAM Isolation
Out-of-Scope Activities
  • NER / Heuristic Statistical Misses: Context-dependent missed names, uncommon formats, or false positives are detection tuning items rather than security vulnerabilities.
  • Denial of Service (DoS / DDoS): Volumetric network traffic flooding or automated scanner bombardment directed at static edge hosting (Vercel / Cloudflare CDN).
  • Third-Party Payment Gateways: Vulnerabilities residing strictly inside Paddle.com or PayPal hosted checkout iframes outside our origin control.
  • Social Engineering & Physical Access: Phishing, pretexting, or physical intrusion attempts targeting personnel or infrastructure providers.
  • Theoretical Best-Practice Reports without PoC: Automated scanner outputs regarding non-exploitable headers on static marketing pages without demonstrable impact.
Detection Tuning: Submit via Support DeskProhibited: Volumetric DDoS & Phishing

3. Reporting Protocol, PGP Key & Report Builder

Submit encrypted vulnerability disclosures with deterministic reproduction metadata.

View /.well-known/security.txt

Send all vulnerability reports directly to our security engineering desk at support@privacyscrubber.com. For sensitive proof-of-concept exploits, encrypt your submission using our PGP key below:

PGP Fingerprint:8B2E 94F1 A7C3 519D 00E4 782B C619 4480 E35A 91BC
Security Desk: support@privacyscrubber.comKey ID:0xE35A91BCRFC 9116:Active through 2027-05

Interactive VDP Report Template Generator

Select the target deployment surface to pre-populate a structured RFC 9116 / ISO 29147 triage template.

Surface: Web Workspace (v2.6.0) 
[PRIVACYSCRUBBER VDP REPORT — RFC 9116 SAFE HARBOR]
Target Surface: Web Workspace (privacyscrubber.com — Client RAM / Web Worker v2.6.0)
Vulnerability Class: [DOM XSS / Zero-Egress Bypass / Crypto Vault / ReDoS]
Estimated CVSS v3.1 Severity: [Critical / High / Medium / Low]

1. Affected Component & Environment:
   - URL / Module: https://privacyscrubber.com/ (Web Worker / IndexedDB Vault)
   - Browser & OS: [e.g. Chrome 140 on macOS / Airplane Mode Offline]

2. Proof-of-Concept (PoC) Reproduction Steps:
   - Step 1: [Provide deterministic synthetic input or DOM payload]
   - Step 2: [Observe DevTools Network / Memory heap behavior]

3. Security Impact & Verification:
   - Does this bypass Zero-Server Processing (ZTDS) or leak in-memory surrogate tokens? [Yes/No]

4. Researcher Attribution Preference:
   - Hall of Fame Credit: [Name / Handle / URL or Anonymous]
Zero synthetic PII only — never include real third-party personal data in PoCs.
< 24 Hours
Initial Triage SLA

Acknowledgment & encrypted tracking reference.

Stage 1: Receipt Confirmation
< 72 Hours
Validation & CVSS Score

PoC reproduction & severity classification.

Stage 2: Engineering Reproduce
< 14 Days
Patch Release & Advisory

Cross-plane fix & Hall of Fame attribution.

Stage 3: Coordinated Disclosure

4. Security Researcher FAQ

Clarifications on local testing environments, safe harbor boundaries, and public advisories.

How should I test for data exfiltration or cryptographic flaws without triggering CDN rate limits?
Because PrivacyScrubber executes 100% locally in client memory, all core scrubbing, Web Worker OCR/PDF parsing, Argon2id key derivation, and XChaCha20-Poly1305 session handoffs can be audited offline after initial page load or by inspecting the local packages (npx @privacyscrubber/mcp-server and npm i @privacyscrubber/sdk). Never run volumetric automated traffic floods against privacyscrubber.com static CDN endpoints.
Are regex false negatives or unmasked context-specific patterns eligible as VDP vulnerabilities?
Standard pattern omissions or statistical NER edge cases are classified as detection accuracy enhancements rather than security vulnerabilities. However, if a specially crafted input causes catastrophic backtracking (ReDoS) that freezes the browser worker thread, or if a malformed token triggers DOM XSS during reverse de-tokenization, that vector is strictly in-scope under our VDP.
How does coordinated disclosure and Hall of Fame attribution work once a fix is shipped?
Once our security engineering team validates your report and deploys a synchronized patch across all affected planes (Web, Chrome Extension MV3, MCP Server, and NPM SDK), we publish a formal security advisory and credit your name, handle, or organization in our Security Hall of Fame (unless you request anonymity). We ask researchers to observe an embargo until the patch is live or 14 days have elapsed from validation.