Locally. Every time.

The data flow

There are two flows in Sessyn, and only one of them touches a network.

Browser event
    ↓
Sessyn extension
    ↓
Local classification   (rules already on your device)
    ↓
Local policy decision
    ↓
ALLOW / RESTRICT / PARTITION / BLOCK

Endpoint contacted: none

The second flow is the rule update. Sessyn downloads a signed, versioned dataset and evaluates it locally. It never asks a server "is this a tracker?", because that question would reveal what you are reading.

sessyn.net
    ↓
Signed, versioned ruleset
    ↓
Extension verifies signature
    ↓
Rules stored locally
    ↓
Browsing evaluated on device

Why blocking does not reveal anything

Sessyn uses the browser's own declarativeNetRequest engine. We hand the browser a list of rules and the browser applies them. Sessyn is not in the request path and does not observe what it blocks. This is why Sessyn does not request the webRequest permission that would expose every URL you load.

Classification, with its working shown

Every entry carries a confidence level, and Sessyn acts accordingly:

Confidence	Meaning	Sessyn will
Verified	Documented by the provider or directly observed	Enforce
High	Strong corroborating evidence	Enforce
Likely	Consistent with known behaviour	Enforce, and say it is likely
Possible	Weak signal only	Explain, not enforce
Unknown	No classification	Leave alone, unless you chose Lockdown

A blocker that treats a guess as a fact breaks websites and loses your trust. Sessyn would rather tell you it does not know.

What Sessyn will not claim

Sessyn can tell you a privacy signal was sent. It cannot tell you a company honoured it, because that happens on their servers. You will never see "this website agreed not to track you", because we cannot verify that.

Equally, a cookie usually holds an identifier — not a dossier. Sessyn will say "this identifier may let the provider associate this browser with data on its servers". It will not invent what that data contains.