Security & data — Meezan ERP POS

Offline by construction

Nothing is sent anywhere

This is not a privacy policy promising restraint. It is an architectural fact about the build: there is no code path that talks to a remote host, because the application does not contain one.

There is no server for the interface to talk to — the renderer calls straight into the Electron main process over an in-process IPC bridge, which reads and writes one JSON file in your own user-data folder. Renderer, bridge, file: that is the entire data path, and none of it touches a network interface.

The practical test is the honest one: unplug the network cable, disable the wireless adapter, and keep trading. Nothing degrades, nothing queues up waiting to sync and no feature quietly stops working, because none of them ever depended on a connection. A restaurant with a dead internet line still takes payments, prints kitchen tickets and closes its shift.

What that means in practice

No network calls anywhere in the application, at any point in its lifetime.
No server, no listening port. The interface reaches the data over an in-process IPC bridge — there is nothing on the network for anyone to find.
Your database is one JSON file on your disk, in a folder you can open, copy and back up yourself.
Activation is offline too. There is no licence server to call, so there is no licence server that can be down.
It runs with the internet unplugged — permanently, not as a degraded mode.

Deliberately absent

Things this product does not have

Most of what goes wrong with restaurant software is not a breach. It is a dependency you did not know you had. These are the ones we removed by design.

No cloud account. Nothing to sign up for, nothing to be locked out of, no password reset email that never arrives on the busiest night of the year.
No telemetry. The application does not phone home with usage, crashes, versions or anything else. We do not know how you use it, and we cannot find out.
No analytics. No embedded trackers, no third-party scripts, no identifiers.
No per-transaction fee. Your takings are your takings. Nothing counts your covers and nothing bills you per invoice.
No vendor who can switch your restaurant off. The software is installed on your machine and activated on your machine. There is no remote kill switch, because there is nothing remote.

The shell

The hardened desktop shell

Meezan runs inside Electron, and every one of Electron's dangerous conveniences is switched off. This is the verified posture of the shipped build.

`contextIsolation: true`

The page's JavaScript runs in its own context, separated from the preload bridge. Nothing loaded into the window can reach into the privileged side and rewrite it.

`nodeIntegration: false`

The interface has no access to Node's APIs. There is no require to reach for, so a stray script has nothing powerful to call.

`sandbox: true`

The renderer process runs inside the operating system's sandbox with the same restrictions a browser tab gets. Escaping it is the hard problem, not the easy one.

A CSP on every response

A Content-Security-Policy is set on every response the embedded server returns — not on the entry page alone. Nothing may be pulled in from outside the application bundle.

Navigation and window-open guards

The window cannot be navigated away to another origin, and it cannot open a new application window. Both are intercepted before they happen rather than cleaned up afterwards.

All permission requests denied

Camera, microphone, geolocation, notifications — every permission request is refused. A point-of-sale system has no business asking where your restaurant is.

External links open in your browser

A link to the outside world is handed to your default browser, where it belongs. It never loads inside the application window, so nothing external is ever rendered next to your ledger.

No server, no port, nothing to find

There is no embedded server at all. The interface talks to the main process over a synchronous IPC bridge — a direct in-process call, not a network request — so there is no listening port for another machine to discover, let alone reach.

No filesystem surface in the renderer

This is the one worth reading twice. The interface has no ability to touch the filesystem at all. Every file operation — an export, a backup, a printed PDF — goes through the narrow IPC bridge (one file, read/write/clear) or a native save dialog you click yourself. There is no path for the renderer to read or write an arbitrary file, so there is no path for anything running in it to do so either.

Switching users asks for their password

Picking a different account and entering that account's password is what changes who the app treats as signed in. Read this plainly: passwords in the database are stored as entered, not hashed — see Where the honesty stops below.

Authorisation

Who can do what

This is a single-user desktop application, not a multi-tenant service — there is no separate server tier to enforce a role independently of the interface. Read this section as what the app does, not as a claim that a modified copy of the app could not be made to do otherwise.

Password-checked account switching

Everyone works under their own named account. Switching to a different one on the same machine asks for that account's password before the view changes.

Three roles

Admin, Accountant and Viewer, as a label on each account. Give each person the role that best describes their job.

Checked before it posts

A malformed number, an unbalanced entry or a posting to an account that does not exist is refused before it reaches the ledger — checked in the app's own posting logic, the same logic every screen shares, rather than left to become NaN somewhere inside a report.

Audit posture

Posted journal entries cannot be edited in place

This is the control that matters most in an accounting system, and it is the one most often missing. A posted journal entry is immutable. To correct a mistake you post a reversal, then post the correct entry. The original stays in the journal, the reversal stays next to it, and anyone reading the books afterwards can see precisely what happened and when.

Two related rules are enforced the same way: an unbalanced entry is rejected outright, and a posting to an account that does not exist is rejected — both checked before anything is written, not caught afterwards by a report that happens to notice.

An audit trail that can be rewritten is not an audit trail. Making a correction take two entries instead of one edit is a deliberate trade, and it is the right one.

Where the honesty stops: passwords are not hashed. User passwords in the database — including the seeded admin123 — are stored and compared as plain text, not through bcrypt or any hashing algorithm. On a single-user desktop machine that only you have a login for, this matters far less than it would on a shared server; it still matters if this machine is ever shared, and it is why the first thing to do after installing is change the admin password and treat this machine's own login the way you would any other machine that holds your books.

Storage

Your data, in files you control

There is no proprietary vault and no encrypted blob only we can open. Your books are a database file and a plain export, in folders you can open in your file manager right now.

Where the live database lives

Platform	Location
Windows	`%APPDATA%\Meezan ERP POS\`
macOS	`~/Library/Application Support/…`
Linux	`~/.config/…`

The mirror that survives an uninstall

On a throttle, the database is mirrored to Documents/Meezan ERP Restaurant/. Plain, human-readable files: the latest export, dated snapshots and a copy of the database.

That folder is untouched by an uninstall. Remove the application completely, reinstall it months later, and your books and your activation are both still there waiting. It is also the folder to copy onto a USB stick and take out of the building each week, because a backup that lives in the same room as the computer does not survive the same fire.

How the writes are protected

Atomic writes. A backup is written to a temporary file and swapped into place, so an interrupted write cannot leave you with half a file.
Writes are fsync'd rather than left sitting in the operating system's cache waiting for a power cut.
A rolling .bak is kept beside the primary file.
Automatic fallback. If the primary is corrupt when the application opens it, the backup is used instead — without asking you to work out what happened at seven in the morning.
Manual export and import from the File menu, whenever you want a copy of your own.

You can copy the folder to another machine and it restores.

Licensing

Licensing, honestly

A licence check is a security mechanism, so it is worth explaining rather than hiding. Ours is offline, node-locked and cryptographically signed.

Activation uses Ed25519 signatures. Only the public key ships inside the application — the private key never leaves us, so an activation cannot be forged or extended by anyone holding a copy of the software, including us on a machine we were never asked about.

The signed message is machineCode|expiry. Both halves matter. The machine code is derived from a stable hardware identifier on that computer, so a code issued for one machine is meaningless on another. The expiry is inside the signature, so changing a single character of the date breaks it.

The machine code is shown to you in the activation window in the form MZR-DE07-EB9C-0099-17AA-7118. You send it to us; we return an activation code shaped as <YYYY-MM-DD>.<base64 signature>; you paste it in. That is the entire exchange.

What this buys you

No internet required to activate. There is no licence server, so there is nothing to be unreachable at the moment you need it.
A reinstall stays activated. The licence is mirrored alongside your data, and the machine code is stable, so the application starts straight in.
No surprise cut-off. The activation code is valid for a fixed period — one year by default — and that expiry is printed in the signature you were sent. When the period lapses the application returns to the activation screen, and a fresh code issued against the same machine code restores it. Your data is never touched.

Release process

How releases are checked

Correctness in an accounting system is a security property. A build that quietly stops balancing costs you more than a build that quietly stops starting.

49 automated tests

Three suites run before every release: persistence (durable writes, backup and restore), the Electron-adaptation regression suite, and the licensing module. Nothing here is mocked — the persistence tests write and read real files on disk.

Worked examples, not just "it runs"

Inside that suite, the parts most likely to be wrong quietly are checked against a worked example with a known answer: FIFO/weighted-average costing, cost-centre and combined-statement arithmetic, the approval engine's posting gates, POS-session cash-over/short, and batch/lot FEFO consumption. A change that breaks the maths fails the build, not just a smoke test.

The packaged app is booted, not just the source

A separate Electron integration smoke test boots the packaged application in a hidden window and probes it for a live render, a working IPC round-trip and zero console errors — not just the source running under a development process, which is where this class of bug likes to hide.

The importer previews before it posts

The CSV/paste importer for opening balances and invoices parses and shows a preview — balanced and unbalanced counts, accounts that do not yet exist — before anything is written, so what is about to change is checked by eye rather than assumed.

The detail behind all of this, including the individual assertions, is in the documentation.

Responsible disclosure

Reporting a problem

If you believe you have found a security issue in Meezan ERP POS, please tell us before you tell anyone else, and give us the chance to fix it.

Write to finance@northbeam.sa with the version you are running, your operating system, and the steps to reproduce what you found — the reproduction is the part that turns a report into a fix. Screenshots and the contents of File ▸ Open Log Folder help. Please do not include a password or a customer's personal data in the report; we do not need either.

We will reply within one business day, which is the same response target as ordinary support, and we will tell you plainly whether we can reproduce it and what we intend to do. We will not ask you to sign anything before we take the report seriously.

Support hours are Sunday to Thursday, 9:00–18:00 AST. For anything that is not a security issue, the contact form is the quickest route.

Keep your books where you can see them

One installer, one database file, no account and no connection. Install it and check every claim on this page for yourself.

Request the installer Book a demo

Your books never leave your building