QR codes and friendly tokens

Every share on this site comes with a QR code, drawn in your browser by the pinned release's QR module from the link itself. Nothing is sent to make it; it is an SVG of the same characters you can copy. A phone's camera opens the link, and the key in the fragment reaches the phone's browser and no server.

That makes the QR code the first way to hand a link over when the two people are in the same room, on a call with a screen, or when one of them is on a phone and the other is not. It replaces the step that broke most hand-overs before: reading out or pasting a long key. The code carries everything the link carries, so it is as secret as the link: do not put it on a slide you will publish.

A friendly token fits in a smaller square

river-cloud-3847 is sixteen characters where a link with a random key is ninety. The QR code is smaller and scans from further away, and the token can also be said aloud or typed. The transfer id and the key are both derived from the token in both browsers, so the server never maps a token to anything and never sees it.

The trade: there are 1,024,000,000 tokens, and anyone holding the ciphertext can try them offline at 600,000 PBKDF2 rounds each. A random 256-bit key cannot be tried. So a friendly token is for a link that expires, a file that is not worth that effort, and a moment when speaking it is the point; a random key is for everything else. The send page shows which you chose and the expiry you set.

Scanning

This release draws codes; it does not scan them. A phone's camera app opens a scanned link in the browser, which is the common case. Scanning with the page's own camera is proposed and listed as such in the reality file.

Compatibility

A link or a token made here opens on send.sgraph.ai, and one made there opens on the open page here: the fragment grammar, the token derivations and the word list are the same, copied from the SG/Send repository and held by tests. The contracts are written down on the API's site.