Skip to content

Digital Research

Why Local-First Research Tools Are Useful for Public Data

If the data is public, why does it matter where the analysis runs? Because the query is not the same thing as the data.

Subdex · 2026-08-22 · 3 min read

There is an obvious objection to local-first tooling for public data: the data is public. Nothing is being protected. Why does it matter whether analysis runs in a browser or on a server?

The objection misses that the data and the query are different things, with different sensitivities.

The query is the sensitive part

A Reddit comment is public. The fact that a particular journalist searched for a particular username on a particular afternoon is not.

Search logs are a record of who is investigating whom. In aggregate they reveal what a newsroom is working on before publication, which accounts a researcher considers significant, and which topics an organisation is quietly interested in.

None of that is in the public data. All of it is in the query log.

So "the data is public" answers a question nobody was asking. The question is who learns what you looked for.

What local-first does and does not fix

Being honest about the limits matters more than the marketing.

It does not hide your query from the archive. The archive lives on someone else's server. Your browser has to ask it, and the archive receives the query and your IP address. Any tool claiming your searches never leave your device is either proxying (which moves the problem) or wrong.

It does remove one intermediary. Without a server in between, there is no second log, no operator who could be compelled to produce one, and no accumulated history of everything everyone searched.

It removes the breach surface. A tool with no search database cannot leak one. This is a structural property rather than a promise about good practice.

It removes the incentive. A company holding a database of who researched whom has an asset, and assets get monetised, subpoenaed, or acquired. Not holding it removes that entire trajectory.

The reproducibility argument

There is a second reason, unrelated to privacy.

Analysis that runs in your browser over records you retrieved is analysis you can inspect. The dataset is a file you have. The transformations are code you can read. If a figure looks wrong, you can check it.

Server-side analysis returns a number. You can trust it or not, but you cannot audit it, and you cannot reproduce it in six months when the service has changed or shut down.

For research intended to be checkable — journalism, academic work, anything with a methods section — that difference is substantive rather than philosophical.

The real tradeoffs

Local-first is not free, and pretending otherwise is the same failure as pretending queries never leave the device.

Nothing syncs. Research saved in one browser is not in another. Exporting is the only way to move it.

Clearing browser data destroys it. There is no server-side copy and no recovery.

Your machine does the work. A very large export uses your memory, and a slow device is slow.

Scale has limits. Analysing millions of records belongs in a database, not a browser. For that, the archives publish bulk dumps.

These are real costs. They are worth paying for a research tool where the sensitive artefact is the question rather than the answer — and worth refusing where it is not.

Where the line falls

Local-first suits tools whose queries are more sensitive than their data: public-records research, archive search, anything where what you looked for is the interesting part.

It suits collaborative tools and large-scale analysis badly, and choosing it there produces a worse product for no privacy gain.

The useful question is not whether local-first is better in general. It is whether the sensitive thing in your particular tool is the data, or the question.

Related tools

Related reading

Archive coverage varies and records may be incomplete. Verify important findings against original sources where available.