"Anonymous" is a claim, not a feature. For WeSearch it means no real-name requirement, no email required to read or participate, and a random-key reader identity rather than a public personal profile. It does not mean that no technical data exists: Cloudflare and server logs process normal request metadata, Google Analytics measures public-page traffic, and Google Translate processes homepage translation requests. The exact boundary matters more than a slogan.
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. Expect WeSearch requests, Cloudflare delivery, Google Analytics, and—on the homepage—Google Translate. You should not see Meta Pixel, DoubleClick ad auctions, Criteo, AppNexus, PubMatic, Rubicon, or other retargeting and programmatic-ad vendors. That is the boundary we commit to and disclose.
What the response layer looks like
Look at HTTP response headers and browser storage on a fresh visit. WeSearch itself primarily uses localStorage for reader keys and preferences, while Cloudflare, Google Analytics, Google Translate, and feature providers may set their own cookies or similar identifiers. The privacy commitment is no ad targeting or personalized news ranking—not an inaccurate promise that the browser will contain zero identifiers.
What's in localStorage
On your first reaction or comment, the site writes a local API key (32 bytes of random hex). It also writes small UI preferences such as the last category picked, tour-completed flag, and BYOK keys you entered. Most values remain local; a value is transmitted when its feature needs it—for example, an API key in the Authorization header or a BYOK credential forwarded to the provider you selected. 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 ad-funded news sites rely on programmatic auctions and retargeting vendors. WeSearch is funded by community donations instead of display advertising, so it does not need an advertising profile or ad-auction stack. Limited operational analytics remain separate from that business model and are disclosed.
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. Expect WeSearch, Cloudflare, Google Analytics, and—on the homepage—Google Translate; confirm there are no display-ad or retargeting vendors.
- Open DevTools → Application → Cookies. Review any cookies created by delivery, analytics, or translation providers against this disclosure.
- 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) to inspect which operational services it blocks.
- View page source and confirm the disclosed analytics and translation integrations match what actually loads.
Limits of our anonymity model
- Server access logs include IP. Standard for any web server; rotated within 30 days. We do not deliberately join those logs into a reader profile, but timestamps and request metadata can sometimes be correlatable.
- 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?
The reader identity is a random key, not a required real-name account. DevTools also lets you verify the disclosed operational services and the absence of ad-targeting vendors.
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 know I visited?
Google Analytics runs on public pages, and the homepage loads Google Translate, so Google can receive browser and request data for those services. We do not use that data for advertising or personalized news ranking.
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.