Limits
What Kionel does not do.
Security tools are chosen by people who have to defend the choice. Read this before buying rather than after; it is the same list our internal threat model carries.
Kionel protects
- File content in transit, sealed before the first frame is shown
- Integrity: a delivered file that differs from the dispatched hash is rejected
- Who signed: dispatch and delivery, by two separate keys
- Order of approvals, chained so a removed link is visible
- Independent verification, offline, without us
Kionel does not protect
- A compromised endpoint: malware or a screen recorder defeats everything above
- An operator who skips the code comparison
- Malicious file content — optical transfer does not scan or sanitise
- Who a person is: a receipt proves keys signed, not people
- That a file was read, understood or acted on
- Coercion: a forced approval looks like an approval
- Traffic analysis: an observer sees that a transfer happened
- Screen emanation (TEMPEST): no claim is made
- Old systems: it needs Chrome or Edge 137 or later, Firefox 130 or later, or Safari 17 or later, so it does not run on Windows 7 or 8.1
Limits of individual features
- Offline package. It sends and, on a computer with a webcam, receives; phones use kionel.com. Trusted timestamps are only in the website version, because the package contacts no service. It needs Chrome or Edge 137 or later. It never updates itself: a newer version has to be downloaded, checked and copied like the first one. A licence loaded into it lives in that browser's storage on that PC, like on the website.
- Stopwatch. It uses the device's own clock, starts at the first code received and stops at delivery. It is a practical measurement, not a certified one, and it is not part of the signed records.
- Seal printed on paper. The code on the paper carries the signed record, not the file, but it is not encrypted: anyone who scans it can read the file name, size, SHA-256 and the work-order fields. Treat the paper like the record itself.
- Colour code from a phone camera. The colour code is made for a clean recording in which the code fills the picture. A phone filming a monitor from arm's length often reads nothing, because video compression blurs the small colour cells; in our own test it read none of 429 images. Use "Fast — recording" there.
- Files carried on a USB stick. Kionel shows that the file that arrived is the file that was sealed, and both devices sign for it. It does not encrypt the file on the stick, does not control the USB port, and does not scan the stick; a file can still be copied without being sealed. Where the reason for avoiding USB is malware or confidentiality in transit, use the optical route or a one-way cable.
- Pinned senders. Pinning says which key may send, not which person or which machine: a key copied from a compromised sending PC is accepted like the original. There are no certificates and no revocation service; to stop accepting a sender, clear the list and pin again. The list lives in this browser's storage and goes if the browser's data is cleared, after which any sender is accepted again until one is pinned. The check for a repeated transfer applies to serial links, because it uses the transfer log; recordings and printed pages can be read again on purpose.
- Pairing by sound. The sending PC needs a working microphone and a clock within two minutes of the receiver's. The sound is audible and can be heard, recorded or imitated by anyone nearby; it carries nothing secret, and an imitated offer shows up as different comparison codes, so the comparison must not be skipped. A PC paired this way has no camera, so it cannot scan the delivery receipt; the receipt comes back as about four seconds of sound and the PC checks its signature against the file it sent. If that sound is not heard, the delivery itself is unaffected and the signed receipt can still be exported on the receiving device.
- Colour code read live. Experimental and slower than filming the screen; recording remains the recommended way to read colour codes.
- Saving to a folder. Chrome or Edge on a computer only; phones and other browsers download instead. After the browser restarts it asks once for permission again, and until then files are only offered for download. It writes files; it does not talk to your LIMS, which has to import from that folder itself.
- Trusted timestamps. They need internet on the receiving device. DigiCert's public service makes no availability promise: if it does not answer, the receipt is issued without a timestamp and the app says so. A timestamp proves when the receipt existed, not when the file was created on the instrument.
- SHA-256 checker. Reads the whole file into the browser's memory, so it stops at 1 GB; larger files need the command for your system.
- Printed pages. Up to 60 pages. Printer and paper quality matter: a faded or creased page may need a rescan, and the dense setting needs a sharp laser print. The pages are only as confidential as their code; printing the code on them makes them readable to anyone who holds them.
- Watching a folder. Chrome or Edge on a computer, with a receiver card. The folder is checked every three seconds, and a file is sent once it has not changed for two seconds. Nothing comes back over a one-way cable, so a file sent while the receiver was off or not listening is not resent by itself; the sender's transfer log shows what went, and starting again with the existing files included fills the gap.
- Serial cable. Chrome or Edge on a computer. It is one-way by wiring, not by certification; a USB serial adapter is a USB device where USB is locked, so use a built-in COM port or have the adapter allowed. The sender gets no confirmation back and offers to send more.
- Operator field. The name is what the person at the sending PC typed. The signature proves it was written with the transfer and not changed afterwards; it does not prove who typed it. Where that matters, pair it with the PC's own login records.
Where time comes from
Without a trusted timestamp, the time in a receipt is the device clock, and two parties who agree could backdate it. Switch on Add a trusted timestamp on the receiving device and each receipt carries an RFC 3161 token from DigiCert: an independent authority's signature that the receipt, with both device signatures, existed at that moment. The token is checked in the browser and by the offline verifier against DigiCert Trusted Root G4, pinned by its fingerprint; a receipt without one says plainly that the time came from a device.
What is still unproven
- No independent security audit yet. We will not use the word "audited" until someone outside has done it.
- No published device matrix yet. Speed and success rates on real phones, screens and lighting are unmeasured, so we promise no throughput figure.
- Qualification is not validation. A signed qualification report does not replace your IQ/OQ/PQ, supplier audit or change control.
- Accessibility. Aligning a camera and comparing codes are visual acts. The codes can be read aloud by a screen reader; audible and haptic alignment feedback is not built yet.
When you do not need us
Kionel fits
- The air gap has to stay and the file still has to move.
- USB is banned or leaves no record you can show an auditor.
- Small files: results, certificates, methods, configurations.
Use something else
- A printed QR code already carries your data (up to about 3 KB) and costs nothing.
- The instrument PC may be networked, or an approved USB route with its own audit trail exists.
- You need bulk throughput — a data diode moves gigabits; we move kilobytes.
- Your site bans cameras outright.
What "no server" means precisely
File content never reaches a server: the transfer happens between your two devices. The enterprise services for device enrolment and revocation, and trusted timestamps if you switch them on (one receipt fingerprint, never the file) do use our infrastructure. Both sentences are true and we say them together. The security model shows exactly where the boundary sits.