Security

hopli · last updated 2 September 2026

How hopli protects a transfer, and where it doesn't.

Written to be checkable rather than reassuring. If a claim here is wrong, it should be possible to demonstrate that.

Phone to your own desktop

Your desktop generates its own certificate and shows you its fingerprint in the pairing code. Your phone accepts that key and no other.

This is stronger than ordinary HTTPS, not weaker. Normal web encryption trusts roughly 150 certificate authorities, any of which could vouch for an impostor. hopli trusts exactly one key, and it reached your phone through your own camera.

Phone to phone

The invitation carries a key that never touches a server. Your device seals a pairing message with it and leaves the sealed result in a mailbox of ours; the key itself travels only in the QR code or the link, from one screen to one camera. The mailbox holds ciphertext under a random 128-bit name and can read none of it.

An invitation works once. The moment a pairing completes, the invitation is finished and says so to anyone else who opens it. Codes are replaced roughly every minute while you wait, and any unclaimed one is deleted within fifteen minutes at the outside.

The connection itself is a WebRTC data channel, which is encrypted by DTLS whether we ask for it or not.

Why you compare numbers

Someone who photographs your pairing code holds the same fingerprint and the same token you do. They could reach your desktop.

So both devices generate a random value and combine them into eight digits unique to that connection. An impostor's screen shows different digits than the phone in your hand. If they don't match, deny it — that mismatch is the whole point.

Digits rather than pictures, because emoji are drawn differently on Windows, Android and iPhone, which would make honest pairs look like mismatches.

Nothing moves without you

Every file is announced before it is sent. Nothing is written to either device until the receiving side agrees, and a prompt left unanswered is treated as no — silence is never consent.

Every completed transfer is checksummed on both ends. A file that arrives altered is discarded rather than saved, so a corrupted transfer cannot sit in your folder looking fine.

A device that has not paired can do nothing at all. It cannot send a file, put a reaction on a message, rewrite one, or delete one. There are tests that hold each of those in place.

A message is text, never code

Messages arrive from a device we do not control and can carry formatting, so the code that draws them is a security boundary. It never assembles markup: every part of a message becomes a text node or an element created by name, so a message containing <img onerror=…> is a message about an image tag and cannot be anything else. Colours and sizes select from a fixed list rather than becoming style, so nothing arriving over the wire can restyle the page.

Addresses become links only for http, https and mailto, decided by parsing the address rather than by reading the front of it — a check that looks for "javascript:" is one you get past with a capital letter. Where a link's words do not already say where it goes, the destination is shown beside them, because words and destination that disagree is the oldest trick there is.

What hopli does not protect against

Being honest about the limits, because a security page that only lists strengths is marketing.

Screenshots and screen recording. hopli cannot stop either, and no website can — there is no browser API for it, on any platform. If it matters that the person you are sending to cannot keep a copy, hopli is the wrong tool and so is every other web page.

Who you talked to, and when. The mailbox sees that an invitation was created and collected. The STUN servers see your IP address. Neither sees content, but the fact of a connection is not hidden. hopli is private about what you send, not anonymous about the fact that you sent it.

This website could be tampered with. hopli's phone side is a web page. Whoever controls the host serving it could serve different code — and that code would be doing your encrypting. Every browser-based encrypted product has this property; most do not mention it. Only a store-signed app would close it.

A notification is handled by your operating system. If you turn them on, the sender's name and the text of the message are passed to the OS to be drawn on your lock screen. That is how notifications work everywhere; if it is not what you want, do not turn them on.

A compromised device. If something malicious is already running on your phone or desktop, it can read your files directly. No transfer tool can fix that.

Approving without looking. The prompts only work if you read them. hopli tries to keep them rare so they stay meaningful.

Reporting a problem

If you find a vulnerability, please report it privately before publishing, and give a reasonable window for a fix. Serious findings are welcome; the full threat model lives with the source and goes into more detail than this page.