For IT providers
Written for the person who has to approve this on a client network. It includes the parts that look wrong at first glance, because you will find them anyway.
A tray application in the signed-in user's session. Deliberately not a Windows Service, and that choice is worth explaining because it usually gets queried.
A service running as LocalSystem has no user network credentials, so it
cannot write to a UNC share without a domain service account and the standing
permissions that implies. A tray app inherits the signed-in user's existing share
access and can write exactly what that person could already write, and nothing more.
No new privileged identity is created on the network.
The trade is that documents are delivered while someone is signed in. A PC sitting at the login screen accepts nothing; queued documents wait on the phone and arrive after the next sign-in.
| Path | What travels |
|---|---|
| Phone to PC, same network | An encrypted blob. Nothing else — no cloud service is involved and no copy is kept anywhere. |
| Discovery | mDNS, so the phone can find the PC by name rather than by typed IP. Can be switched off; the address can be entered manually. |
This is the question that reads badly on a checklist, so here it is up front. The connection between phone and PC on your own network is plain HTTP. The payload crossing it is already encrypted end to end.
Each document is sealed on the phone, to the specific PC it was paired with, before it is sent. The filename, the destination folder and the document type are inside the encrypted region — not headers, not metadata. In this market a folder name is a client name, so none of it travels in the clear.
Adding TLS underneath would mean shipping a certificate for a machine on a private network with no public name — which in practice means a self-signed certificate the phone is told to trust, or a certificate authority you now have to operate. Both add a trust decision without adding secrecy the payload does not already have. The bytes on the wire are opaque either way.
An attacker on the same network sees that a phone sent something of a certain size to a PC. They cannot read it, cannot tell you what it was called, cannot tell which client it belongs to, and cannot send one of their own.
The signature is not optional. A PC's public key is displayed on its own screen, so anyone who has seen that screen could encrypt something to it. Only the signature makes a delivery attributable, and the PC refuses anything not signed by a device on its own pairing list.
Pairing is a QR code shown on the PC and read by the phone. That matters more than it looks: the code carries the PC's public keys over light, off a screen the person is standing in front of — the one channel an attacker on the network cannot reach or substitute.
The pairing code is single-use, expires after three minutes, is compared in constant time, and is cancelled the moment the window closes. Revoking a phone deletes its key rather than flagging it, so there is no check that can be missed. A pairing table that cannot be read loads empty — it fails closed.
On the PC, keys are protected with DPAPI, scoped to that user and bound to the application. On Android they are held in the Android Keystore. Keys never leave the device that generated them; pairing exchanges public keys only.
The receiving app writes files it was sent into folders you nominate, so it decides what it is willing to write:
.exe, .bat, .ps1,
.lnk and similar) are refused regardless of that list, and cannot be
allowed back in.invoice.pdf.exe is an executable.Files are written to a temporary name inside the destination and then renamed into place, so a watch-folder feeding a line-of-business system never sees a half-written file. An existing file is never overwritten — a counter is added instead.
For a local delivery, nothing. No server is involved in a delivery between a phone and a PC on the same network, and no telemetry of document contents exists anywhere.
A phone contacts our servers exactly twice in its life: once to register, and again if its registration is renewed. Neither carries a document, a file name or a folder name. A delivery never waits on us — if our servers are unreachable, or gone, documents still arrive. The receiving PC checks a phone's registration with a signature it can verify by itself, offline, so nothing on the delivery path depends on anything we run.
The application checks for updates over HTTPS against a static manifest. That check can be turned off.
If your review needs something not covered here — a specific control framework, a penetration test report, data-processing terms — ask. A direct answer, including "not yet", is more useful to you than a page that implies otherwise.