Why privacy tools shouldn't need your password: building a local-first email analyzer

Most people have dozens of forgotten accounts scattered across the web. Every newsletter, free trial, ecommerce store, and service you signed up for in 2018 still holds your personal data.

When you look for tools to clean this up, you run into an ironic problem:

Almost every inbox cleanup service asks you to grant full access to their cloud servers to scan, index, and store your email metadata. To reduce your exposure to third parties, you have to hand your inbox data to another third party.

I did not want that. So I built Paperweight. It is a fully open-source, local-first desktop application that scans your inbox, maps your account footprint, helps you bulk unsubscribe, and creates GDPR deletion requests.

All processing happens directly on your machine. No emails or personal data ever touch external servers.

Open source and zero server exposure

Paperweight is not open-core or a proprietary SaaS wrapped in marketing terms. The entire codebase is 100% MIT-licensed on GitHub, where it recently passed 300 stars.

Most commercial inbox cleaners monetize by:

1. Running server-side parsers on user data.
2. Ingesting email headers and metadata into cloud databases.
3. Aggregating anonymized consumer purchase trends or telemetry.

If a tool is marketed as a privacy utility, local-first is the only architecture that makes sense.

Traditional Service:
[Your Inbox] ---> [Cloud Server / 3rd-Party DB] ---> [Web UI]
                       (Privacy risk / PII liability)

Paperweight:
[Your Inbox] ---> [Local SQLite on Device] ---> [Desktop UI]
                       (Zero cloud ingestion)

By keeping everything strictly local:

• No PII liability: We do not hold user emails, tokens, or account inventories.
• No GDPR or cookie overhead: Because there are no user tracking databases, there is no risk of leaking user data.
• Full auditability: Anyone can inspect the network calls and verify that no telemetry or inbox data leaves their device.

Architecture and under the hood

The stack is intentionally simple:

• Frontend and desktop shell: Electron, TypeScript, and React with Tailwind CSS.
• Storage: Local SQLite database on the client machine for indexed metadata, scan history, and account classifications.
• Email ingestion: Direct IMAP connectors and desktop OAuth flows (PKCE for Microsoft, loopback OAuth for Google).
• Classification engine: Local regex patterns and phrase lexicons that run heuristics across headers, MIME structures, and email bodies to identify:
  • Bulk and marketing newsletters
  • Account registrations and transactional receipts
  • One-click unsubscribe headers (List-Unsubscribe) and body fallback links
  • Cross-references against known data breaches via HaveIBeenPwned

Technical tradeoffs of local-first

Building a desktop-only inbox analyzer comes with challenges that server-based apps do not have:

1. Zero telemetry and blind debugging

In a typical SaaS, if a parsing regex fails or an IMAP provider returns an unexpected response, error trackers catch it immediately. In Paperweight, because we refuse to collect user payloads or crash telemetry containing personal emails, debugging relies on user issue reports, reproducible test fixtures, and automated test suites.

2. Multi-language lexicon scaling

Email unsubscribe conventions and registration phrases vary across languages.

In English, scanning for phrases like "manage your preferences" or "unsubscribe here" is straightforward. In German, Dutch, French, or Japanese, the patterns change completely.

Rather than running remote LLMs, Paperweight uses lightweight per-language phrase lexicons stored as simple data files.

How to contribute

Paperweight is developed in public as open-source infrastructure.

Because the classification engine uses lexicon files, you do not need deep engine or Electron knowledge to contribute:

1. Add or refine language lexicons: Our phrase classification files live in analysis/src/data/lexicons/. Adding support for your native language is a single-file pull request.
2. Add IMAP presets and GDPR deletion endpoints: Help expand custom provider presets or direct contact routes for automated deletion requests.
3. Audit and star the project: Check out the codebase, test it on your own inbox, or star the repo on GitHub to follow along.

Links and resources

• Website: paperweight.email
• Source code: github.com/wslyvh/paperweight
• License: MIT