DEV Community

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

Posted on Originally published at paperweight.email

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

#opensource #webdev #privacy #showdev

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)
Enter fullscreen mode Exit fullscreen mode

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

Top comments (1)

Collapse
 
presend profile image
Presendapp •

The multi-language lexicon problem is underrated — most "just use an LLM for classification" takes ignore that regex-based, auditable heuristics are exactly what you want when the whole pitch is "nothing leaves your device." On the HaveIBeenPwned cross-reference: are you doing the k-anonymity range query (5 hash chars) locally, or checking against a bundled/cached breach dataset? Curious how you kept that step consistent with the zero-network-call promise.