How to verify that a web app never uploads your files
Haven Zip team · · 2 min read
Most online archive tools work by uploading your file to a server, processing it there, and sending back the result. Their privacy pages say the upload is deleted after an hour. You have no way to check that. Haven Zip works differently: the archive engines run as WebAssembly inside your browser, and the file never leaves your device. That is a claim too, but it is one you can verify yourself, and this article shows how.
Step 1: open the Network panel
In Chrome, Edge or Firefox press F12 (or Cmd+Option+I on a Mac) and choose the Network tab. Clear the list and keep it open. Every request the page makes from now on will appear here with its size.
Step 2: open an archive and extract it
Drop a RAR, ZIP or 7z into Haven Zip. You will see a few requests: the WebAssembly engine files (7z-wasm and libarchive, a few megabytes, cached after the first visit) and nothing else. Now extract the files. The list stays quiet. There is no POST request, no request whose size matches your archive, nothing carrying its name.
For a stronger test, disconnect from the network after the page has loaded, then open and extract an archive. It works. An app that uploaded files could not.
What you will see, and why
You will see two kinds of requests: static assets from the same origin, and a small analytics script from analytics.ipekbayrak.com.tr that counts page views without cookies. If you have Do Not Track enabled, even the custom events are skipped. Neither request carries anything about your files; the code that runs is open in the page source for anyone to read.
- Same-origin requests: HTML, CSS, JavaScript, the WebAssembly engines, icons.
- One analytics script: anonymous page view, no cookies, no file data.
- Zero requests while extracting, compressing or converting.
Why this design
Browsers can now run the same compression engines desktop tools use, at native speed, through WebAssembly. Once that is possible, uploading a file to do work on it is a liability with no benefit: it costs bandwidth, it is slower than local processing for anything larger than a few megabytes, and it makes a promise about deletion that cannot be audited. Doing the work locally removes the promise, because there is nothing to delete.