Offline is a claim that has to be checkable

Your files never leave your device.

That sentence, or one close enough to it, appears on the front page of a great many document tools. It is short, it is reassuring, and the person reading it has no way of finding out whether it is true. That last part is the interesting one, because a claim nobody can check is doing something other than informing you.

The uncomfortable version is that most privacy statements about desktop software are unfalsifiable by the audience they are aimed at. You are being asked to trust a sentence, and the sentence is written by the party with the strongest interest in it being believed. That is not an accusation against any particular product. It is a description of the position everybody is in, including us, and it is worth setting out what can be done about it rather than adding another confident paragraph to the pile.

What separates a checkable claim from a comfortable one

A claim is worth something to you in proportion to what it would take to catch it being wrong. "We respect your privacy" cannot be wrong; there is no observation that contradicts it. "This feature works with the network disconnected" can be wrong, and you find out in about a minute. Between those two ends sit most of the sentences on most software websites.

The second test is scope. A statement about what a program does is different from a statement about what the operating system will permit it to do, and the two get blurred constantly, usually in the direction that sounds better. A vendor can honestly describe its own code. It cannot honestly promise you a boundary the platform does not enforce.

What you can actually check on Windows

Here is the ladder, cheapest first, with what each rung is worth.

1. Turn on airplane mode, or pull the cable, and use the software. This tests one thing well: whether a feature genuinely runs locally, or whether it was quietly sending work somewhere and rendering the answer. What it cannot tell you is what happens when you are connected. A program can queue and send later, and offline capability is not the same claim as no transmission.
2. Watch the process while you use it. Resource Monitor has a network tab that lists connections by process; netstat at a command prompt does a plainer version of the same thing. This is observation rather than enforcement, so you have to be looking at the right moment, and a single short request during a save is easy to miss.
3. Add an outbound block rule in Windows Firewall for the program's executable, then use it. This one is enforcement rather than observation, applied by you and not promised by anybody. Two caveats matter. An application can consist of more than one executable, and a rule naming one of them says nothing about its helper processes. And the way you learn a rule was doing something is by a feature breaking, which is a slow signal.
4. Capture traffic. Windows has a packet capture facility built in, and there are the usual tools beside it. This is the highest-fidelity check available to a user, and it still has an honest limit: modern traffic is encrypted, so what you learn is who was contacted and when, not what was said. Who was contacted is usually the part you cared about.

Every rung on that ladder is available to anybody with a Windows machine and no special access. Together they are a reasonable answer to a reasonable question, and they are better evidence than any sentence a vendor writes, including this one.

What a full-trust desktop application cannot promise

Windows has a sandbox model where an application declares the capabilities it needs and the system enforces the list. Under that model an application without the network capability does not get the network, and that is a real boundary rather than an assurance.

It applies to applications running in an app container. A conventional desktop application does not run in one. Full trust means what the name says: the process has the user's own privileges, and one of the things a user is allowed to do is open a socket. So a desktop application's manifest can omit every networking capability and the omission changes nothing about what the process is able to do. It is a declaration of intent. It is not a wall, and describing it as one would be the exact failure this article is about.

This is why a browser is in a genuinely stronger position for this particular question, and it is worth conceding rather than talking around. A page runs inside a boundary the browser enforces, and the developer tools built into every browser show you every request it makes, with no cooperation required from the people who wrote the page. Desktop software has no equivalent, and no desktop vendor can manufacture one by wording.

Reading the package will not settle it either

The suggestion that comes up next is to look inside the installed files. It is a fair instinct, and the mechanics are easy: a Windows MSIX package is a zip archive, and the import tables of the binaries inside it list the functions each one expects to find at load time. The tools for reading them are ones a developer already has.

Then two things go wrong with it as a proof.

An import is not a call. A binary can list a function it never reaches on any code path, and the presence of a socket-related import proves that something in the dependency graph was compiled against it, not that anything invokes it. Meanwhile the absence of an import proves less than it looks like it does, because functions can be resolved by name at run time, and a managed runtime ships networking libraries regardless of what the application on top of it uses.

The other thing is specific, and we would rather write it here than have somebody find it and conclude we were hiding it. Take our package apart and you will find tesseract.dll importing getaddrinfo, through a dependency of the OCR stack. No OCR feature reaches it, and an import is not a call. The .NET runtime alongside it carries networking libraries our code never calls, for the same structural reason.

So the import tables will not settle the question either way. That is the honest thing to say before sending anybody to read them, and it is the reason the invitation and the disclosure have to travel together.

The claim we make, and its edges

Given all of that, here is the narrow version, which is the strongest thing we can say that is also true.

There is no code in this application that makes a network request. The build asserts it. That is a statement about our code, and not about what the operating system permits, because Windows does not enforce a network boundary for a full-trust desktop application.

Note what the second sentence is worth to you, which is less than it is worth to us. The build assertion is a test that fails our own build; you cannot run it, because the source is not published and this is not open-source software. It is a real constraint on us and it is our word to you, and those are different things. The trust page sets out the same boundary at more length, and the licence expressly permits taking the installed package apart to check what we say about it.

Then the parts that do not fit the tidy version. Turn on airplane mode and every feature still works except one: the optional timestamp on a digital signature, which you switch on yourself, and which sends a hash of the signature — never the document — to a time authority you pick from a list. We collect no telemetry. Windows crash reporting can still send diagnostics to Microsoft, possibly including data from an open document, and that is not ours to switch off. And a separate cloud product is planned under the same name; it does not exist yet, and it will never be a feature inside this application, but it is better that you hear about it from us than find it later and reread everything above in a different light.