Skip to content

This website is currently under construction. Content may be incomplete or subject to change.

CERNIS PRO
DE

Privacy & Trust

CERNIS PRO is built so you can trust it without having to. Privacy here is not a setting you have to find — it is the architecture.

The promise in one paragraph

There is no CERNIS server the application talks to. There is no account for you to create. There is no telemetry sending data in the background. Everything CERNIS learns about your network stays on your machine — in a local database you control. And because CERNIS PRO is open source, you do not have to believe us: you (or someone you trust) can read the code yourself.

The five privacy principles

  1. 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. 2

    Passive wherever possible

    The most sensitive observation functions — above all SNI capture and live monitoring — work passively: they read along with what happens anyway instead of generating traffic or “interrogating” devices. That is gentler on the network and more respectful of the devices.

  3. 3

    Do not store what need not be stored

    The passively captured SNI data (which app contacts which host name) is deliberately not stored permanently. It serves the live overview and is gone afterwards — privacy as a design decision, not an afterthought setting.

  4. 4

    Facts with a source, not a verdict

    When CERNIS tells you something about a remote peer, it shows the source for every detail — and withholds judgement. You see where a piece of information comes from and keep the power of interpretation. No black box that says “dangerous” or “safe” without reason.

  5. 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 usage statistics, no crash reports to a server, no advertising IDs.
  • No account, no login, no subscription. You download it and use it. Full stop.
  • No cloud storage: your 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 your traffic — it observes and explains.
  • No hidden privilege escalation: anything needing elevated permissions is named openly.

“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 you a traffic light — you never know why, and you cannot object. CERNIS PRO turns that around. It treats you 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 you. A tool that hides nothing from you is one you can trust for good reason.

Free software (GPL)

CERNIS PRO 2.0 is licensed under the GPL — the GNU General Public License. A careful licence audit documents the compatibility of all bundled components. For you this means:

  • Verifiability: the source code is open. Every claim on this page can be checked against the code.
  • No backdoors by design: with open software, hidden misbehaviour is far harder to conceal.
  • In your hands: you may use, study and share the software — and depend on no single vendor.

Technical basis for trust

CERNIS PRO 2.0 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 whose boundaries are enforced automatically on every build (import-linter, 8 contracts).
  • Fully type-checked: strict static type checking (mypy strict) — no dead paths, no silent errors.
  • Testing as a gate: the complete test suite is a gate every build must pass.
  • Security audit: a full audit of version 2.0 is documented; 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.