Rules Go Out.
Nothing Comes Back Unless You Send It.

Integrity

Rulesets are signed with ECDSA P-384, and the public key is embedded in the extension. The private key is non-exportable inside an Azure Key Vault HSM, so signing is a remote operation and the key cannot be copied off — including by whoever is doing the signing.

A signature is checked on your device, not on the server. That is the point: whoever serves this file cannot change what your browser enforces, so a compromised host, a mis-issued certificate and a hostile proxy all fail the same way — the update is rejected and the installed rules stay.

Current status: remote rule fetching is live. Updates are fetched, verified and applied only when the signature checks out and the version is newer than the one installed; the ruleset shipped inside the extension is the floor and is never replaced by an older one. One signature is required: ECDSA-P384, from a key held in an Azure hardware security module that signs only after a person approves the change with a passkey (ADR-0021). The earlier post-quantum ML-DSA-65 signature was retired in 0.2.65; current builds refuse a ruleset that still carries one rather than half-check it.

Where These Rules Come From

Every rule above cites at least one source with a retrieval date, and the strongest evidence is the least dramatic kind: a provider's own documentation describing what its own product does. After that, browser and web standards, then standards bodies, then published regulatory findings. A cookie database or another blocklist is treated as a lead to investigate, never as proof on its own — copying a blocklist would import its mistakes along with its coverage.

Candidates are researched automatically, and that research cannot publish anything. It produces a proposal that a person has to promote by hand, and it is held to a deliberately low ceiling: an automated proposal may never claim the top confidence level, because a machine cannot confirm that a page says what it is claimed to say. Since an allowlist entry and the essential, security and preference categories all require that top level, automated research structurally cannot produce them — it can only ever suggest something be blocked or restricted, and only a person can agree.

Before a proposal is even written down, every citation is opened to check it exists, and at least one must be the operator of that endpoint documenting its own behavior, or a standards body or regulator. Sign-in, bot-defense, payment and certificate endpoints are refused outright: a wrong block there locks someone out of their bank rather than costing them an advertiser. Those two mistakes are not equally expensive, and the rules are not written as though they were.

The confidence levels these rules carry, and what Sessyn will and will not do at each one, are set out in how it works. The full sourcing policy — the hierarchy above, what is not admissible, and the review cadence — ships in the project repository as docs/rules/RULE_SOURCES.md.

Disputes and Corrections

If you operate a domain classified here and believe it is wrong, write to contact us with your evidence. Corrections are published with a changed review date.

Classification is never for sale. Sessyn will not accept payment to allowlist a tracker or to describe tracking as essential — that is written into the project's monetization guardrails, not left to good intentions.

Machine-Readable Endpoints

No endpoint answers a question about a URL or a hostname. One accepts browsing input: reports.sessyn.io/v1/reports, which takes only a report a person chose to send, in a fixed format, and refuses anything else. It names the sites that person captured, so it is not anonymous; it never contains page addresses, cookie values, times or identifiers. It is on its own host, deliberately not behind Cloudflare, so the report is encrypted all the way to Sessyn's server, and no request log is kept for it. Sessyn will not operate an API that could be turned into an open proxy or an internal-network scanner.