"Anonymous" is a claim, not a feature. Many sites that call themselves anonymous don't require sign-up but still load Google Analytics, Meta Pixel, AppNexus, Chartbeat, and a long tail of audience-measurement vendors that profile you across the web regardless of whether you typed an email at the door. The combination of "no sign-up" and "no tracker stack" is what we mean when we say WeSearch is genuinely anonymous.
This page is the verifiable, technical version of the anonymity claim — what's actually in the request layer, what's in the response, what's in browser storage, and what we have on the server.
What the request layer looks like
Open DevTools on any WeSearch page and watch the Network tab during a load. You will see HTML, CSS, JS, fonts, and (on story pages) an OG image proxied through our origin. You will not see any of the following: google-analytics.com, googletagmanager.com, connect.facebook.net, doubleclick.net, chartbeat.com, quantserve.com, scorecardresearch.com, amazon-adsystem.com, criteo.com, appnexus.com, pubmatic.com, rubiconproject.com, openx.net, bidswitch.net, casalemedia.com, contextweb.com, mathtag.com, adnxs.com, everesttech.net, tapad.com, krxd.net, or any of the dozens of other vendors that fire on a typical news site.
What the response layer looks like
Look at HTTP response headers on any WeSearch page. Cache-Control, Content-Type, Content-Encoding — that's what's there. You won't see Set-Cookie: __ga=..., you won't see Set-Cookie: _fbp=..., you won't see Set-Cookie: __qca=..., and you won't see any cookie at all that survives a tab close on a fresh visit.
What's in localStorage
On your first reaction or comment, the site writes a single key: your local API key (32 bytes of random hex). It also writes small UI preferences (last category picked, tour-completed flag, BYOK keys you entered). None of these get sent to our server except the API key in the Authorization header. Inspect with DevTools → Application → Local Storage → wesearch.press.
What we have server-side
For each reaction or comment you post: a hash of your API key (which we cannot reverse), the URL, and the body or reaction code. For each push subscription: an opaque endpoint id from the browser vendor's push server, again tied to a hashed key. For story view counts: aggregate integer counters per story, not per-user. For server access: standard rotated logs with IP, user-agent, and request path, kept 30 days.
Why this is rare
Most news sites would lose their primary revenue stream (advertising) if they removed the third-party tracker stack, because the auction layer behind display ads requires those vendors to be in the request path. WeSearch is funded by community donations instead of advertising, which means we can run without the tracker stack at all. Not because we're more virtuous; because we picked a funding model that doesn't require it.
Anonymity in the comment layer
Comments appear under a generated handle ("Plain Loom 638"). Two people who comment on the same story have no way to tell whether the other person is one of their friends, a coworker, or a stranger. The platform doesn't have that information either; we have a hashed key, not an identity. Full anonymity stance.
How to verify our claims yourself
- Open DevTools → Network on any WeSearch page. Filter by domain. Confirm only wesearch.press requests appear (plus Google Fonts CSS for typography).
- Open DevTools → Application → Cookies. Confirm you see at most a single first-party preference cookie, no third-party cookies.
- Open DevTools → Application → Local Storage. Confirm only the wesearch-namespace keys are present (your local API key, UI prefs, OG cache).
- Run a request-blocking extension (uBlock Origin, Privacy Badger). Confirm the blocker has nothing to block on WeSearch.
- View page source and search for known tracker domains. None should appear.
Limits of our anonymity model
- Server access logs include IP. Standard for any web server; rotated within 30 days. We don't tie IPs to your hashed reader key in a correlatable way, but the IP is in the log line.
- Email recovery is opt-in. If you enable email recovery, the email is hashed before storage but you've still given us a piece of identifying data. Skip this option if anonymity is critical.
- Cross-device sync requires email recovery or manual key transfer. Anonymity has friction; a more anonymous model is also a less convenient one.
- Push notifications use a vendor endpoint. The endpoint is opaque (no identifying data) but it does represent a relationship between your browser and the push gateway.
Bottom line: who is this anonymity model for
- Readers who simply don't want their reading habits profiled by an ad-tech vendor.
- Journalists working with sources who need a non-attributable platform for discussing news.
- Activists, dissidents, or readers in jurisdictions where reading certain news could create risk.
- Researchers studying online discourse who want to participate without building a public-platform identity.
- Anyone tired of being asked to "create an account" before reading a free article.
Frequently asked
Are you actually anonymous, or just claiming it?
Verifiable in DevTools. Run the steps above. The structural absence of trackers is the test.
If a court ordered you to identify a user, what would you give them?
A hashed key, the comment(s), and the IP that posted them (within the 30-day log retention). We can't reverse the hash. We've received zero such requests to date.
Will Google still know I visited?
If you typed wesearch.press in a Google search, Google saw the search. WeSearch can't change that. Once you're on the WeSearch page, Google has no further visibility — we don't load Google scripts.
Can my employer or ISP see what I read?
They can see you visited wesearch.press (TLS hides the path/content from your ISP but not the host). Your reading habits aren't visible to them at story-level granularity over HTTPS.