Privacy & Trust
CERNIS PRO is built so it can be trusted without having to. Privacy here is not a setting to hunt for — it is the architecture.
The promise in one paragraph
There is no account to create. There is no CERNIS cloud backend the application could not run without, and no licence server that would have to grant an activation. There is no telemetry sending data in the background. Scans, histories and stored results remain on the user’s machine — in local databases and files under the user’s control. Some functions do fetch data from the internet, because they could not work without it; the section “When CERNIS PRO contacts the internet” below sets out which ones they are and what becomes visible on the outside. And the source code is open: the user (or someone they trust) can read the code themselves instead of having to believe the promise.
The five privacy principles
- 1
Data sovereignty first
CERNIS consistently prefers local and own sources over third-party services. Wherever information can be determined locally, it is determined locally. Even mapping IP addresses to countries and network operators uses a local database rather than a foreign online service.
- 2
Passive wherever possible
The most sensitive observation function — SNI capture — works passively: it reads along with what happens anyway instead of generating traffic of its own or “interrogating” devices. That is gentler on the network and more respectful of the devices. Where a function has to measure, it does so openly: live monitoring, for instance, sends its own check requests to the detected gateways and to two preset internet references; users can add their own targets.
- 3
Do not store what need not be stored
The passively captured SNI data (which app contacts which host name) serves the live overview and is gone afterwards — privacy as a design decision, not an afterthought setting. Anyone who wants to keep these observations switches on the recording of external contacts; the derived host names are then stored permanently — like everything else: on the user’s own machine.
- 4
Facts with a source, not a verdict
When CERNIS says something about a remote peer, it shows the source for every detail — and withholds judgement. It is visible where a piece of information comes from, and the power of interpretation stays with the user. No black box that says “dangerous” or “safe” without reason.
- 5
Never more permissions in secret
CERNIS never takes elevated system permissions in the background. If a function needs more, it says so openly. Solved technically via privilege separation: only a tiny, specialised helper (cernis-sniffd) carries the permission needed for passive reading — not the whole application. The attack surface stays minimal.
What CERNIS PRO does NOT do
- No phoning home: no transmission of usage statistics, no crash reports to a server, no advertising IDs.
- No account, no login, no subscription. Download it, use it. Full stop.
- No cloud storage: scans and histories are local, nowhere else.
- No advertising, no tracking, no data selling. The business model is not a data business.
- No silent blocking: CERNIS does not interfere with the traffic — it observes and explains.
- No hidden privilege escalation: anything needing elevated permissions is named openly.
When CERNIS PRO contacts the internet
Some CERNIS PRO functions require internet access. These connections serve only the function concerned. CERNIS transmits neither telemetry nor usage statistics and uploads no scans or histories. As with any internet access, at least the connection’s public IP address is visible to the other end and, depending on the function, so is the specific request.
- Live monitoring Live monitoring starts with the application and checks the detected gateways and two preset internet references at short intervals: Google Public DNS (8.8.8.8) and Cloudflare DNS (1.1.1.1). Users can add their own targets.
- Vulnerability cross-check When the cross-check is active, CERNIS fetches the matching entries for the devices and services found from a public vulnerability database by itself — including when nobody is at the machine.
- Blocklists When blocklists are switched on, CERNIS reloads them regularly from their respective publisher. With no list switched on, this does not happen.
- Only at the press of a button Some requests are triggered by the user alone — the external IP and port check, loading an operator name, resolving a remote peer. They never run by themselves.
“Show, don’t judge” — why that is a mark of trust
Many security products decide in the background what is good and bad, block silently and give a traffic light — with no reason given and no way to object. CERNIS PRO turns that around. It treats the user as a capable person who is allowed to see the truth about their own network and judge for themselves. It provides facts, explains connections, shows sources — and leaves the decision to the user. A tool that hides nothing is one that can be trusted for good reason.
Free software (GPL-2.0-only)
The packages shipped for CERNIS PRO carry the licence declaration GPL-2.0-only — the GNU General Public License in version 2. The licence information of the bundled components is collected afresh with every build, separately for each target platform. For the user this means:
- Verifiability: every claim on this page can be checked against the source code.
- No backdoors by design: with open software, hidden misbehaviour is far harder to conceal.
- In the user’s hands: the software may be used, studied and shared — with no dependence on a single vendor.
Technical basis for trust
CERNIS PRO is not a cobbled-together script but a thoroughly structured, tested application. For those who want to know exactly:
- Clean structure: a hexagonal architecture with clear layers. The CI quality gate checks their boundaries with import-linter (8 contracts).
- Fully type-checked: strict static type checking (mypy strict) is a fixed CI quality gate and catches type errors before release.
- Testing as a requirement: the automated test suite runs as a fixed CI quality gate.
- Security review carried out by the project itself: a full, documented security review of the rebuild exists; findings were fixed or deferred in a traceable way.
- An honest error culture: if a tool or a permission is missing, it is made visible — nothing is silently swallowed.