Paper backup of files using QR codes

I've been working on this on my own implementation.

There's an easy solution that already exists. Par2 is a recovery file which generates Reed Solomon codes. It's a packetized format, so you can zero pad each packet to fit in a QR code and the programs will still read them.

The downside is that you need to be aware that recovery packets are 64 bytes larger compared to the recovery block size.

If you don't care about exact alignment, you can just use Par2 as is. If you do, I am currently working on Par2Py, which will allow for alignment and for using an optional packet type that stores the data itself inside the Par2 file itself.

The advantage of this approach is if you do one Par2 packet per QR code, then not only can you recover from some codes missing, but you can also recover from codes being scrambled!

Originally posted by @EmperorArthur in https://github.com/za3k/qr-backup/issues/2#issuecomment-890360305

I wanted to open this issue as a more open-ended alternative to the pull request I made (#25). I definitely think that a higher storage density (on paper) can be achieved than the defaults currently provide, which would save paper and storage space.

Version 40 does not appear to work to any reasonable degress when printed. However, after doing some experimentation, I have found that QR version 25 with error correction level "H" can be used to fit a 4x3 grid of codes onto a page which, when printed, can be scanned reliably by both my phone (which is a mid-range Android from 2018) and a scanner, and can reliably reproduce a valid backup without any issue.

Please give it a try and let me know what you think.

This is just a small modification that enables the QR code data to be printed to stdout by using the --human-readable-stdout flag, so that it can, for example, be piped to a text file and printed off.

It's not pretty, but it easily and effectively adds an important layer of redundancy. In case 1 or more QR codes becomes corrupted, the data can still be recovered by manual entry.

The flag itself was chosen so that it doesn't collide with a more well-integrated --human-readable flag that would presumably be added to the document using Pillow.

This would essentially require qr-backup --restore... there's no easy command-line programs to do this. Try to make it restorable without qr-backup if there's no damage.

Edit: could also support shamir's secret sharing scheme

Screenshot of the problem is requested--author uses a tiling window manager and didn't think about this.

Do people find the preview useful? It can just be turned off entirely.

EDIT: Using Pillow 8.2.0 generates uncorrupted PDFs.

Hello, this program is generating broken PDFs that do not display in any PDF view that I have tried, with the exception of Chrome.

In Linux, the PDF fails to open in Evince, Firefox, and Libreoffice Draw (this one crashes).

On Adroid, the PDF works in an old Google PDF reader app that I use, but fails in Moon Reader.

In all apps that display the PDF without crashing, the PDF looks the same: like a noisy, streaky mess.

I am using Xubuntu 21.04 x64.

I have tried a couple different files with the same result. To show my issues, I have attempted to create a backup of CHANGELOG from the latest commit (currently 926355d85ddd3fb8878da07e5cf464d47fb14569).

Here is a link to the PDF generated: https://filelink.org/kRWFohOf6Lur0RZ Here is an image of how it looks on my computer (on anything other than Chromium) and on Android Moon Reader: https://ibb.co/6J9XGJC

Here are the versions I have installed (via pip freeze from a venv):

Pillow==9.0.1
qrcode==7.3.1

Here is my terminal output from when I created the file:

(venv) user@host:~/code/git/qr-backup$ ./qr-backup CHANGELOG -v
INFO:root:Original arguments were: []
INFO:root:Command arguments parsed. Equivalent command: qr-backup --qr-version 10 --dpi 300 --scale 8 --error-correction L --page 500 600 --compress --filename CHANGELOG
INFO:root:read file CHANGELOG (sha b8d63ca5584ffa66aea55851e6fb9f60b5a10542086a95cfba2b5cd6479870a4, 2.731KB)
INFO:root:Restore command is: sort -u | grep "^N" | cut -c6- | base64 -d | gunzip
INFO:root:9 qr codes (at version 10) total
INFO:root:QR code (including label) is: 520x520px
INFO:root:Page is: 2083x2500px
INFO:root:4 x 4 qr codes (at version 10) per page. 1 pages total
INFO:root:1326 bytes in 1 (2.73KB/page)
WARNING:root:Skipping digital restore verification, because zbarimg is not available.

The default QR code version used (version 10) results in the creation of many QR codes. This requires many more scans (and thus, much more effort) than the the highest-density QR code version 40. Furthermore, version 40 codes have higher information density over a given area that version 10, meaning their usage will save both time and paper.

Therefore, this simple pull request is to change the default QR code version from 10 to 40.

Add a human-readable mode, in which the original file is printed along with the QR codes (the same data on the page should match the data in the QR codes). One row of QR codes per page max seems reasonable.

In the FAQ, it says: "Make sure your document doesn't contain weird characters (including "\r", the mac/windows newline), or base64 encoding will turn on, which makes recovery harder."

However, it seems there's no conditional use of base64 encoding in the code, and alpha strings are always encoded:

$ echo -n ipsum > ipsum.txt
$ qr-backup --no-compress -o ipsum.pdf ipsum.txt
$ zbarimg ipsum.pdf 
QR-Code:N1/1 aXBzdW0=
scanned 1 barcode symbols from 1 images in 0,04 seconds

Add a separate command line tool text-backup which generates a text-mode backup instead of using QR. It should be keyed back in by hand.

Ideas:

• Include checksums and ECC per-line
• Can we make it "readable" if the original is text, so that you don't have to key in some text to read other text?
• Try to make it easy to type? BIP39 wordlist, PGP word list, etc may be a good option but then need the wordlist to decode.
• Generate .txt by default with a .pdf option

This will require factoring out the "QR" backup, restore, and test process from the rest of the logic. Could be done before or after adding erasure coding.

IMPORTANT: This doesn't work currently. There seems to be a bug in the reedsolo library. It has been reported at https://github.com/tomerfiliba/reedsolomon/issues/34

This required removing the proprocessing step of base64 encoding. Instead, we base64 encode each QR code independently (always). Sadly this does make the data a little less readable while debugging. Closes #2.

During webcam restore, missing codes are listed as "N1", "N2" etc.

It might be reasonable to un-shuffle using prng and hint at position?

• [x] v1.0: Initial release
• [x] v1.1: Feature complete
• [ ] release: Ship in any easy-to-install format
• [ ] v1.2: Support for Windows, Mac, and Android. Add GUI.

Currently, the argument --page allows to set the width and the height (--page 500 600), but the page margins can't be specified. For example, cover instructions basically don't have any margin:

It would be useful to be able to set horizontal and vertical margins like this:

--page WIDTH_POINTS+HOR_MARGIN_POINTS HEIGHT_POINTS+VER_MARGIN_POINTS

Example:

--page 500+15 600+15

It would also allow to center the QR codes on the page.