Security and data flow, written so you can check it
Your documents are parsed, chunked, embedded, indexed and searched inside one browser tab. This page maps each step to where it happens, lists the four layers that keep it that way, and shows how to confirm the whole thing in DevTools.
Last updated:
There is no upload path in this application, so there is no document store, no queue, no log line and no database row containing your files. The only request the site ever makes is a plain file download of model weights, requested by name.
The life of one document, step by step
| Step | Where it runs | Leaves your device? |
|---|---|---|
| You drag a PDF, DOCX, Markdown or plain-text file onto the page | Your browser, in memory, through the local File API | No |
| Format detection | Your browser — magic bytes in the file header, not the file extension | No |
| Text extraction (PDF text layer, Word headings, Markdown structure) | Your browser — the parser is compiled into the site and served from our own files | No |
| Cleaning, chunking, overlap between chunks | Your browser, in a Web Worker | No |
| Vectorisation of every chunk | Your browser — onnxruntime WebAssembly or WebGPU, both bundled with the site | No |
| Index write (chunks plus vectors) | Your browser — IndexedDB, inside your own browser profile | No |
| Model weights, on first use only | A public model host: HuggingFace or a mirror | Yes — a single GET carrying the file name only |
| Your question | Your browser — embedded with the same local model | No |
| Retrieval: vector search and keyword search, merged | Your browser | No |
| Answer assembly, or local text generation | Your browser | No |
| Citations, copy, print, export | Your browser | No request is involved |
| Advertising, on the pages that carry it | Google AdSense, and personalized only after you agree to ad scripts | Yes — page level only, and never inside the chat workspace |
| Deleting everything | Your browser — clear site data | No; deletion is local and immediate |
Four layers of defence
1. The code layer: there is no upload path to disable
The site is a set of static HTML, CSS and JavaScript files. There is no server-side code, no database, no accounts and no endpoint that accepts a document, which means there is nothing to misconfigure later. A content security policy is sent with every page and limits where the page is allowed to connect: the model host and its file delivery host, plus Google’s ad origins on the handful of pages that show ads. Pages like this one carry no ad slots at all, so those origins are never allowed here.
- No analytics SDK, no session recording, no heatmap script, no support chat widget.
- No third-party font or script CDN: the fonts and the onnxruntime WebAssembly build are served from this site.
- The model host is a plain file server. It receives a file name, it hands back a file, and it is never given a place to send anything.
- A page that shows ads still receives no document content, because the ad script runs in the page frame, outside the worker where your text and vectors live.
2. The verifiable layer: watch the traffic yourself
The application has a network shield panel that lists every request the page makes while you work — host, path, size and purpose — and marks anything that is not on the disclosed allow-list. It exists so that a claim on this page can be checked against what your own browser sees, instead of being taken on trust. The DevTools procedure below does the same job with a tool nobody has to trust us for.
3. The disclosure layer: models ask before they download
Any file above 30 MB, and in fact every model file, is behind a panel that names the file, its exact size, its host and its licence before anything is transferred. Nothing is fetched while a page loads, and nothing is fetched quietly while you type. The sizes and licences are listed in full on the models page.
4. The legal layer: commitments you can hold us to
The privacy policy states what is not collected, not merely what is. The terms state that your documents remain yours. Both pages carry a last-updated date, and a change in behaviour is a change to those pages — not a silent release note.
How to verify us yourself, in about five minutes
Open the tool and DevTools together
Press F12, or Command-Option-I on a Mac, and go to the Network tab. Tick “Preserve log” so a reload does not wipe the evidence.
Clear the request list
Use the clear button. You start from an empty list, so anything that appears afterwards is caused by what you do next.
Add a document
Drop in a PDF and watch the indexing progress. The request list stays empty while the browser parses, chunks and vectorises the file.
Ask three questions
Still empty. Retrieval, ranking and the retrieval-only answer path are all local, and the list proves it.
Force the one model request
In a fresh browser profile, or after clearing site data, ask a question again. You will see a single request to the model host. Its path holds the model file name, it carries no query string about your content, no cookie and no request body.
Cut the network and keep working
Switch the Network tab to Offline and ask another question. It still answers, with citations, which is only possible if nothing was being sent away.
Delete everything and see what is gone
Go to the Application tab: IndexedDB holds your chunks and vectors, Cache Storage holds the model weights. Clear site data, reload, and the library is empty. There is no copy elsewhere for anyone to restore.
Security boundaries: what we cannot control
A page listing only strengths is an advertisement, not a security page. These are the risks that sit outside the application, and the app does not pretend otherwise.
- Password-protected or encrypted PDFs cannot be opened. There is no decryption step, so you get an error rather than a partial result.
- Scanned documents without a text layer produce no usable text. No OCR engine ships with the site, and we say so instead of returning an empty answer.
- Size limits are enforced rather than hidden: up to 25 MB per file, 40 files per library, 200 MB in total and 20,000 chunks. Larger collections are refused up front.
- On a shared or public computer, the library lives in that computer’s browser profile. Anyone who can use that profile can open your documents. Use a private window and clear site data when you are done.
- Our storage sits in IndexedDB and is not encrypted by the application. Whatever protects it is your operating system and browser profile encryption, or the absence of both — that part is your device’s job, not ours.
- Browser extensions with permission to read pages can read the page, the text it is showing and the data the page can reach. We cannot block that. Auditing your installed extensions matters more than trusting any website.
- Malware, keyloggers or someone with physical access to your device can do things no browser-based tool can prevent.
- A screenshot, a printed page or a downloaded copy leaves the browser’s protection behind, because it is now an ordinary image or file on a device.
- Loss of local data is a real risk: clearing site data, a browser cleanup tool or a wiped profile removes the index, and there is no backup on our side to restore it from.
Reporting a security problem
Write to guweiicy@gmail.com. Include the browser and version, the steps that reproduce the problem, and what you observed in DevTools if you saw something unexpected. This is a small project with no bug bounty programme, and we would rather tell you that plainly than imply a reward that does not exist. Anything that turns out to be real gets fixed and described in the changelog.