Privacy ·
Zero-server architectures: why local web apps have no file to breach
Zero-server here means: no application database of user files, no upload route, no object bucket of customer PDFs. A breach of the origin still yields HTML, JS, and maybe analytics. It does not yield last week’s bank statements. That is the architectural immunity. It is not immunity to XSS in the live tab.
Threat model: static origin plus ads
Assets are public. Secrets should not be in the bundle. Ads are third-party frames. They must not receive File bytes. Compare that to a convert API with disk full of documents.
Remaining risks
DOM XSS reading the in-memory File, malicious extensions, screenshot malware, and the user uploading anyway to another site. HTML entity encoding and CSP reduce the XSS class.
No account, no credential stuffing of history
There is no “download my past jobs” endpoint. Close the tab, lose unsaved state, same as a desktop utility without cloud sync.
Supply chain
Lockfiles, SRI on third-party scripts (the SRI seed post), and preferring Web Crypto over random npm hashers when the platform already has the primitive.
Honest limits
The share sheet, email, and chat apps are still exfil paths. Zero-server is about our origin, not the user’s entire device.
Frequently asked questions
Can a static site still be hacked?
Yes. Supply-chain JS, XSS, and DNS hijack can run in the victim’s tab and read the File the user just selected. There is still no pile of historical files on the server.
Does no account mean no identity risk?
It removes password reuse against a tool history. It does not remove phishing the user into a lookalike domain.
Are npm libraries in the bundle a server?
No. They execute client-side. They are still a supply-chain review item (pdf-lib, papaparse, marked).