Skip to content
hateitall

Security and architecture

The core security property of this product is architectural: your files are processed in your browser, so there is no server-side copy to breach, leak, or subpoena. This page describes the architecture, the threat model, and how to report a vulnerability.

Last reviewed: July 22, 2026

Architecture overview

HateItAll is a statically generated website. The server's only job is to deliver identical, pre-built assets — pages, styles, scripts, and fonts — to every visitor. All file processing happens in your browser tab:

YOUR DEVICE                                 NETWORK
┌─────────────────────────────────────┐
│  Browser tab                        │
│                                     │     static assets only
│  your file ──► processing engine ───┼──✗  (pages, scripts,
│  (File API)    (canvas / PDF /      │      fonts — same for
│                 spreadsheet /       │      every visitor)
│                 media encoder)      │
│                      │              │
│                      ▼              │
│               verification          │
│                      │              │
│                      ▼              │
│               output blob ──► download (in-memory object URL)
│                                     │
└─────────────────────────────────────┘
   file bytes never cross this line ──✗
  • No file-handling backend: the application has no upload endpoint, no processing queue, and no server-side storage of user content.
  • Engines run in-tab: images use the browser's canvas APIs; PDFs use pdf-lib and pdfjs-dist; spreadsheets use SheetJS; media tools use the encoder and audio pipeline built into your browser. Engine code loads on demand per tool.
  • Outputs are local: results are assembled as in-memory blobs and downloaded via object URLs, which point into your browser's memory rather than at a server.

Threat model

What this architecture protects against

  • Server-side breach of your files: not possible in the usual sense — your files never reach a server, so a compromised server has no user files to expose.
  • Retention risk: there is no “we delete uploads after one hour” promise to trust, because there is no upload to delete.
  • Insider access: nobody who operates this site can read your files, because they are never in our possession.

What it does not protect against

Honesty requires naming the limits. Local processing cannot defend you from problems on your own device:

  • A compromised browser or malicious extension can read anything displayed in any tab, on this site or any other.
  • Malware on your device can access your files directly, regardless of which website you use.
  • A compromised delivery pipeline — if the site's own JavaScript were maliciously altered at the source, it could misbehave. We mitigate this with a pinned, reviewed dependency lockfile and reproducible static builds, and you can audit actual network behaviour at any time via the DevTools verification steps.

Dependency policy

  • Dependencies are pinned via a committed lockfile; upgrades are deliberate, reviewed changes.
  • Processing engines in production: pdf-lib and pdfjs-dist (PDF), SheetJS (spreadsheets), exifr (image metadata parsing), fflate (ZIP assembly). Image and media processing use browser-native APIs with no additional engine download.
  • All engines are bundled and served with the site's own assets — no third-party CDN scripts on tool routes.
  • No dependency on tool routes performs network requests with file content; this is part of what the verification steps let you confirm.

Output verification framework

Privacy-relevant tools do not assume their own output is correct. After processing, each tool reopens or rescans the actual output bytes — re-decoding an image and sampling redacted pixels, reloading a generated PDF and checking page counts and metadata fields, reparsing an exported workbook and searching for structures that were supposed to be removed. The result is one of three statuses:

  • Verified — every declared check passed.
  • Verified with declared limitations — checks passed, but something outside the tool's scope is disclosed (for example, visual blur being present, which is not secure redaction).
  • Failed verification — a check failed; the normal download is blocked rather than labelled safe.

Reporting a vulnerability

If you find a security issue — especially anything that causes file content to leave the browser — please email security@hateitall.com with steps to reproduce, the affected URL, and your browser and version. We read every report and will acknowledge yours. Details on the contact page.