Record: is ology.com a cover? — 2026-09-12

What was asked

The owner put the probability at about 90% ordinary, 10% cover, and asked for suggestions on uncovering a hidden purpose:

“A nefarious site would want to look innocent in exactly this manner. The misplaced address block, the geographic dispersion of servers, and continued existence of an apparently long-failed site — these could all be coincidence, but they would also fit a hidden purpose (say 10% likely). It is possible that examining the client-side HTML and Javascript would show some irregularity, but I do not think this is likely. More likely the key to unlocking hidden behaviors is user input (and/or cookies stored in the client based on a past user-supplied key). I do believe it is possible to construct a web service that gives no clue to its real purpose.”

The first thing to say is the limit. A service that answers every unkeyed request exactly like an ordinary empty service is not detectable from outside, and no amount of probing changes that. What can be done is to discover what the operator intended, and then check whether the live system does more than that, less than that, or something else. That is what this pass did.

The second thing to say is that the client-side examination was worth doing after all, because the client turned out to be published source code.

The operator published the whole stack

The GitHub organization public-square holds the components, and one of them names our target explicitly. The README of psqr-web says:

“The PSQR web app delivers content to readers using browsers and mobile phones… An instance of the progressive web app can be seen at ology.com.”

So this is not a mystery application to be reverse engineered. It is an open-source Progressive Web App, and the deployment at ology.com can be compared against the source it claims to be.

The documented API surface is twelve routes: GET /api/feed/{name}, PUT /api/feed, GET|POST /api/search, GET /api/search/{hash}, GET|DELETE /api/article/{infoHash}, PUT /api/broadcast/{infoHash}, PUT|DELETE /api/identity/{did}, PUT|DELETE /api/list/{listName}, GET /api/permission, GET /api/publisher/{did}, GET /embed/, and GET /link/{infoHash}/{inlineLinkNumber}.

Every hostname we had discovered independently is in that list. There is no undocumented name to explain.

What the live system does now

Each request below is a single well-formed GET, made at the rate of roughly one every two seconds. Nothing was submitted, authenticated, or guessed.

A covert relay would need a backend. There is no live backend on any name we know: the four service vhosts on the block answer 403, 400, 500 and a hang, and the two cloud services do not accept a connection.

The client, checked against its own source

The service worker is the shortcut to a complete client audit: its Workbox precache manifest lists every asset the app installs, so the question “did we miss a chunk?” is answerable without guessing. Thirty-two assets were fetched; four initial failures were transient and all succeeded on retry.

• The live build is the published application plus two feature chunks the published router does not have: feedImport and group, with Groups, identity, publish, permission and sign strings in the settings and list code. That is a newer version of the same application, not an add-on hidden inside it.
• Every external host baked into the bundle is documented: feed.ology.com, broadcast.ology.com, beacon.ology.com, ology.substack.com, and the three archived feed URLs. No websocket, no EventSource, no analytics identifier, no undisclosed endpoint.
• Client state is exactly what the design implies: localStorage for settings, feed configuration and cached DID documents; localforage over IndexedDB for the identity store; and jose-browser-runtime to hold an EC P-384 private key in the browser and sign posts with it.

That last point answers the owner’s hypothesis directly. The “user-supplied key stored in the client” is not a hidden mechanism: it is the documented identity model. A publisher creates an identity, the private key stays in their browser, and the server only ever sees a signature. We cannot see another user’s browser storage, so a keyed interaction between a publisher and the service would be invisible to us — but there is nothing hidden about where it lives.

The structural find: the DNS moved, the old zone did not

This is the most informative result of the pass, and it explains several loose ends at once.

• The domain’s public nameservers are AWS Route 53 (ns-1136.awsdns-14.org, ns-1841.awsdns-38.co.uk, ns-361.awsdns-45.com, ns-929.awsdns-52.net), whose SOA is ns-361.awsdns-45.com.
• ns1.ology.com (23.191.145.2) and ns2.ology.com (23.191.147.3) are ordinary A records inside the reserved block, and both still answer authoritative DNS — from a stale copy of the zone whose SOA serial is 20240501, i.e. 2024-05-01. They are not the domain’s delegated servers.
• The stale copy differs from the public zone in ways that date the migration: it still points id.ology.com at the block (23.191.144.8/.9) where the public zone now points it at AWS, it has no archive.ology.com, and it has no TXT record while the public zone carries google-site-verification=r70fiuFUeSyLGjjPMGhPRS7PWZXHLMc3aautxr1Tq-Q.
• Mail is AWS SES (10 inbound-smtp.us-east-1.amazonaws.com), as it was in the earlier pass. There is no DNSSEC (no DS, no RRSIG), no CAA record, and no wildcard: admin, mail, dev and a random name all return nothing.

So the operation migrated its DNS to Route 53 around May 2024 and its API and identity service to AWS, and left the old nameservers — and the whole web fleet — running inside the reserved block.

Certificates: issuance is current, deployment is not

Certificate Transparency shows a live, automated issuance pipeline, and this is where the “abandoned” reading needs qualification.

Certificates were issued for the whole fleet nine days before this record. What the hosts present, however, is uneven:

Per-name certificates were confirmed on the stale hosts too (feed expired 2025-06-02, beacon expired 2025-06-06), so this is a per-vhost deployment frozen in March 2025, not a single default certificate.

The reconciliation is mundane but worth stating precisely: an automated ACME client is still obtaining certificates, the authoritative DNS pair inside the block is still running, and the web tier that would use those certificates has not been updated since March 2025. Issuance current, deployment stale.

The content was recovered, and it is ordinary

The Internet Archive holds responses from the feed service itself, including one from 2025-07-09. Decompressed, politics-mainstream/latest.jsonl is a 500-record window spanning 2025-01-30 to 2025-02-05, and it shows what the service actually did:

Each record is a signed news item: title, description, canonicalUrl back to the publisher, an infoHash in the style of a torrent, engagement counters (contentLike, contentReply, contentAmplify), a geo field, and a metainfo.provenance block holding an EC P-384 JWK and an ES384 signature over the package. An earlier capture, from 2022-01-07, uses did:web:id.ology.com:thomas-massie — the pre-did:psqr form of the same idea.

That is a mainstream-news aggregator with cryptographic provenance. It is the kind of output the published code predicts, item for item, and the last item was broadcast at 2025-02-05T15:33:48Z — the same season the certificates stopped being deployed.

Third-party sightings

What this does to the 10%

Six independent checks came back the way the ordinary reading predicts, and each one had a chance to come back the other way:

• The client is published source, and the deployed bundle matches it plus two documented feature additions. A hidden capability would have to be in the server, because there is nowhere in the client to put it.
• The refusals are configuration, not authorisation. beacon answers a random path and the documented beacon path with the same 146-byte nginx page. A keyed check would have to discriminate; this one does not.
• Certificate Transparency shows no undisclosed hostname. CT is where a covert deployment leaks, and this one leaks only the names the operator published.
• A third party’s port scan found nothing but 80 and 443.
• The recovered output is a signed news feed from named publishers, with the last item five months before the certificates stopped being renewed — the shape of a venture that ran out of steam, not of a front that must look busy.
• The DNS and certificate trails show migration and partial abandonment (Route 53 in 2024, AWS API, a stale in-block zone, a web tier frozen in March 2025) rather than concealment.

What remains, and cannot be removed by any of the above: a service that ignores unkeyed input is invisible to us, and the identity model means the interesting traffic is between a publisher’s browser and the API. There is no evidence of a hidden purpose, and there is also no way to prove its absence. The honest statement is not “clean” but “no hidden behaviour found across these checks, on a system whose published design already explains everything observed”.

One observation does deserve a second look, and it is not about concealment: the stale in-block nameservers still answer authoritatively for a zone that is no longer the public one. They are, in effect, a forgotten authoritative copy of a live domain inside unassigned ARIN space — reachable by anyone who asks them directly. That is a security curiosity in its own right, and it is worth recording separately from the cover question.

The falsifiers

Evidence that would raise the cover reading: an undisclosed hostname in a certificate; a port other than 80/443 answering on the block hosts; a response that differs for a well-formed versus malformed request to the same route; the identity or API services returning to life with behaviour the published code does not explain; published content that does not match the publisher DIDs; or traffic to these hosts from parties other than crawlers and us.

Evidence that would lower it further: the operator’s own statement; a successful retrieval of the urlscan archive showing only the landing page; the web tier’s configuration files; or the observation, over a longer period, that the certificate renewals stop.

The intrusion ledger

Every request this pass made to the operator’s infrastructure, all of it read-only:

No credentials were guessed, no paths were brute-forced beyond the standard .well-known files, no redirects were followed into third parties, and nothing was submitted. The urlscan account that would have unlocked historical cookie data was deliberately not created.

What this leaves

The cover hypothesis is now substantially weaker on evidence, while remaining unfalsifiable in principle. The venture’s own published design — a signed-article network with per-publisher keys, aggregating mainstream news, deployed on a domain whose operator is named — accounts for every observable, including the ones that looked most like concealment: the unassigned address space, the spread of hosts, and the dead services.

The two genuinely new facts are architectural rather than conspiratorial:

1. The public DNS is at AWS Route 53, and a stale authoritative copy of the zone is still answering from ns1/ns2 inside ARIN-reserved space.
2. Certificate issuance is current (2026-09-03) while the web tier’s deployment has been frozen since March 2025.

Both belong in the site A record, and both are ordinary consequences of a migration that was never finished.

Commits

• (this record)