Security & Responsible Disclosure

How Zoom to Fill is built to hold as little as possible, and how to report a vulnerability if you find one.

Last updated: September 12, 2026

On this page
  1. How the product is built
  2. Reporting a vulnerability
  3. What is in scope
  4. What is out of scope
  5. What to expect from us

Found a vulnerability? Write to contact@zoomtofill.com with enough detail to reproduce it. We read every report, we keep you posted while we fix it, and good-faith research will never be met with legal action. There is no paid bounty program, and we say that up front.

How the product is built

The strongest security property Zoom to Fill has is how little there is to attack. The design decisions below are structural: they are not policies we promise to follow, they are how the product works.

  • Video never leaves your machine. Every effect (cropping, sharpening, motion smoothing, the ambience glow) runs locally on your GPU, on frames your browser already has. There is no server that could see what you watch.
  • No accounts, no passwords. The free extension needs nothing from you, and PRO is activated by email link rather than a password, so there is no credential database to breach.
  • PRO status is a signed token. Entitlement travels in a JWT signed with Ed25519 and verified in your browser against the public key, offline. Forging one requires the private key, which lives only in our API's secret store.
  • Cards never touch our systems. Payment runs entirely inside Paddle's checkout; what reaches us is described in the Privacy Policy, and it does not include payment details.
  • Minimal data surface. The personal data we hold is what a PRO purchase requires, it is deleted on a 24-month clock, and the free extension collects nothing that identifies you.
  • Small, managed infrastructure. The site, the API and the database run on Cloudflare's edge. There are no servers of ours to patch, and the attack surface is the code we deploy.

Reporting a vulnerability

If you believe you have found a security issue in the extension, this website or our API, email contact@zoomtofill.com. Include what you found, where, and the steps to reproduce it; a proof of concept helps. Machine discovery starts from /.well-known/security.txt, which points here.

Please give us a reasonable window to fix the issue before publishing details, and do not access, modify or retain data that is not yours: if a proof requires someone's data, use your own test purchase.

What is in scope

  • the Zoom to Fill extension as published on the Chrome Web Store;
  • this website, zoomtofill.com;
  • our API at api.zoomtofill.com, including its activation and payment webhook endpoints.

What is out of scope

  • Denial of service and other volumetric testing: do not degrade the service to prove it can be degraded.
  • Social engineering of us or of users, phishing included.
  • Third-party services: issues in Paddle, Cloudflare, Chrome or a video platform belong in their disclosure programs, not ours.
  • Automated scanner output without a demonstrated impact: a CVE match on a version string is not a finding until it is exploitable here.
  • Missing hardening headers, SPF/DMARC nuances and similar best-practice notes with no exploitation path.

What to expect from us

  • an acknowledgement of your report;
  • an assessment once we have reproduced it, and updates as things move, rather than silence;
  • credit here or in release notes if you want it, or anonymity if you prefer;
  • safe harbor: research done in good faith and within this policy will not be reported to authorities or met with legal action, and we consider it authorized within the meaning of anti-hacking laws;
  • honesty about rewards: there is no paid bug bounty. What we offer is a fast response, a real fix and public credit.