Security Architecture

Last Updated: March 20, 2026

        ThunderSweep is a Chrome extension (Manifest V3) that scans Gmail and Google Drive for sensitive documents
        entirely within the user's browser. No email content, file content, or personally identifiable information is
        ever transmitted to ThunderSweep servers. This page documents the security architecture, OAuth scope
        justifications, data flows, and security controls in place.
    

1. Application Overview

Type: Chrome Extension (Manifest Version 3)
Developer: ThunderSecurity LLC
Primary function: Local scanning of Gmail attachments and Google Drive files to identify sensitive documents (SSNs, tax forms, bank statements, passports, medical records). Users can move identified files to an encrypted local Vault stored in their own Google Drive.
Server infrastructure: No backend database. Two Cloudflare Workers handle optional anonymous feedback and opt-in encrypted file transfers only (see Section 4).
Google API usage: Gmail API (readonly + modify for user-triggered delete/archive) and Google Drive API (read for scanning, write for Vault operations).

2. OAuth Scope Justification

ThunderSweep requests the minimum OAuth scopes necessary to deliver its core features. Each scope is justified below.

Scope	Why It Is Required	Why a Narrower Scope Is Insufficient
`gmail.readonly`	Read email metadata (sender, subject, date) and download attachment content for local sensitive-data scanning. No content is stored or transmitted beyond the user's browser.	No narrower Gmail read scope exists. `gmail.metadata` is insufficient because ThunderSweep must download attachment binary content to parse PDFs, DOCX files, and spreadsheets locally for PII patterns.
`gmail.modify`	Required for user-triggered actions: deleting an email or marking it as read directly from the ThunderSweep scan results. ThunderSweep never modifies Gmail without an explicit user action.	`gmail.readonly` alone does not permit delete or label modifications. Users reasonably expect to act on found sensitive emails without leaving the extension. No intermediate scope between readonly and modify exists in the Gmail API.
`userinfo.email`	Identify which Google account is connected so users managing multiple accounts can see which account a scan applies to.	No narrower scope for reading the authenticated user's email address exists.
`drive`	Three distinct operations require this scope: Drive scanning: List and read all Drive files to identify sensitive documents the user uploaded or received. Vault write: Create the ThunderSweep Vault folder and write AES-256-GCM encrypted files into the user's Drive. Vault secure-move (delete original): When a user vaults a Drive file, ThunderSweep deletes the original unencrypted copy from Drive after successful encryption — completing a secure move so no plaintext copy remains.	`drive.readonly` would cover scanning but not Vault write or delete. `drive.file` only grants access to files the extension itself created. It does not permit reading or deleting pre-existing user files (uploaded by the user or received via Google Workspace sharing), which is the core use case for both Drive scanning and secure-move. A combination of `drive.readonly` + `drive.file` still cannot delete pre-existing files (only `drive` or `drive.appdata` permits this), so the full `drive` scope is the minimum that satisfies all three operations.

3. Data Flow Architecture

3a. Gmail Scanning

User clicks "Scan" → Background service worker requests Gmail API (HTTPS, OAuth bearer token) → Attachment binary downloaded directly from Google to browser memory → PDF/DOCX/spreadsheet parser runs locally in service worker → Regex patterns match against extracted text → Results stored in chrome.storage.local (metadata only: email ID, subject, detected category) → No content leaves the browser.

3b. Google Drive Scanning

User initiates Drive scan → Background service worker lists Drive files via Drive API → File content fetched directly from Google Drive API to browser memory → Local parsing and pattern matching → Results stored in chrome.storage.local (file name, Drive file ID, detected category — no content) → No content leaves the browser.

3c. Vault Encryption

User clicks "Move to Vault" → File content fetched from Drive to browser memory → AES-256-GCM encryption performed locally using crypto.subtle (Web Crypto API) with a PBKDF2-derived key stored only in chrome.storage.local → Encrypted blob uploaded back to user's Google Drive (ThunderSweep Vault folder) via Drive API → Original unencrypted file deleted from Drive upon confirmation of successful upload → Encryption key never leaves the browser. ThunderSweep servers never receive file content.

3d. TS Share (Optional Encrypted Transfer)

User opts to share a Vault file → File decrypted locally → Re-encrypted with a PBKDF2 key derived from a random 256-bit claim token → Encrypted blob uploaded to Cloudflare R2 bucket (ts-transfer.thundersweep.com) via Worker → Claim token embedded in a one-time link emailed to recipient via Resend (transactional email) → Recipient opens link, claim token sent to Worker, blob downloaded and decrypted in recipient's browser → Blob auto-deleted from R2 within 7 days or on claim, whichever is first → ThunderSecurity LLC cannot decrypt transfer blobs; the claim token is never stored server-side.

3e. Anonymous Feedback (Optional)

User clicks Send on optional feedback form → Message text POSTed to Cloudflare Worker (thundersweep-feedback.lwang-evdy.workers.dev) → Message forwarded to developer email → No email address or account information is included in the request.

4. Security Controls

Content Security Policy

Defined in manifest.json:

"content_security_policy": {
  "extension_pages": "script-src 'self'; object-src 'self'; worker-src 'self'"
}

No inline scripts permitted.
No eval() or dynamic code execution.
All scripts must be bundled within the extension package.

OAuth Token Storage

Tokens are stored in chrome.storage.local, which is isolated to the extension's origin and not accessible to any web page.
Tokens are never stored in localStorage, cookies, or any mechanism accessible to web content.
Tokens are revoked server-side via accounts.google.com/o/oauth2/revoke when the user disconnects an account.

Cryptography

Vault encryption: AES-256-GCM via the browser's native crypto.subtle Web Crypto API.
Key derivation: PBKDF2-SHA-256 with a unique random salt per Vault initialization.
TS Share transfer encryption: PBKDF2-SHA-256 derived key from a 256-bit random claim token; unique IV per transfer.
No custom or deprecated cryptographic implementations.

Input Validation

All Gmail API and Drive API responses are parsed with explicit type and shape validation before use.
External message handlers (e.g., the onMessageExternal listener for TS Share deep links) validate sender.origin against the allowlisted https://thundersweep.com domain and check for required fields before acting.
Content scripts injected into mail.google.com do not execute any content from Gmail messages as code.

Minimum Permissions

The extension does not request clipboardRead, history, bookmarks, cookies, geolocation, webRequest, or any other permissions beyond those documented in Section 2.
host_permissions are limited to Google APIs, the Gumroad license API, and the two Cloudflare Worker endpoints operated by ThunderSecurity LLC.
Content scripts are scoped exclusively to https://mail.google.com/*.

No Server-Side User Data

ThunderSecurity LLC operates no database of user emails, scan results, or Gmail/Drive content.
No analytics, telemetry, or tracking scripts are included in the extension or landing page.

5. Responsible Disclosure

If you discover a security vulnerability in ThunderSweep, please report it privately before public disclosure:

Email: [email protected]
Subject: Security Vulnerability Report
We will acknowledge receipt within 48 hours and aim to resolve confirmed vulnerabilities within 30 days.