And if you can demonstrate that there are functions are computable by a user community that would benefit from them, it would make a fantastic submission to the Symposium on Usable Privacy and Security (SOUPS).
But, most people are trusting software at some point. We're making sure our software is small and relatively simple so that you can audit it. That's one of the reasons why we don't take dependencies on Google's Tessearact OCR engine, or on frameworks like React. (The one big dependency we haven't removed is OpenCV.)
One of my concerns would be durability of the software over time. In 20 years from now, will the site still be running? Will I need to hunt down old hardware or dependencies to regenerate my key?
You can, in fact, do it manually. T4r means letter T, digit 4, facing right. The directions are 't', 'r', 'b', 'l' (top, right, bottom left), which makes for a mnemonic you can follow with "right here in river city".)
Before you transcribe, just rotate the box so that the first letter in the alphabet appears in the top left, than read in English order (left to right, then top to bottom).
We're just figuring out whether to use an MIT license or a license that forbids use in stalkerware applications and anti-citizen surveillance applications.
The current DiceKeys box has latches to make sure it's very very hard to open accidentally or if dropped from human heights.
We have thought about designing a box that's intentionally very easy to open for people who want to encrypt their laptop when traveling into a jurisdiction that may want to steal IP or compromise their journalistic sources. We'd want the user to be able to slip their hand into their pocket and release the dice from the box before anyone knows to ask for their DiceKey.
Correct. We believe a two-bit reduction in strength is a small price to pay to ensure you get the same key even if you scan the box at a different orientation (e.g. up-side down).
We could have designed the software to try to recognize the top of the box, but the box for the steel version may look very different (or not be what you'd think of as a box at all.)
The author of that post is on the DiceKeys advisory board.
At some point, you're going to feed the entropy source into software. Having the app be part of your trusted computing base reduces the chance of a data-entry error that could leave users forever without their data.
Feeding the entropy source into software might take many different forms depending what is the password to (e.g. login/full disk encryption key on your computer, password manager master password, password to a specific online service, etc). For most uses you'll have to enter it as text, and have to enter it multiple times, potentially on different devices that you are accessing the service on.
For almost any real-world use case, memorizing the password and typing it in on a keyboard is pretty much a necessity. There are many kinds of inputs that don't allow another software like DiceKeys to enter the secret, so I'd still definitely rather stick with the simpler, human-readable option.
But, most people are trusting software at some point. We're making sure our software is small and relatively simple so that you can audit it. That's one of the reasons why we don't take dependencies on Google's Tessearact OCR engine, or on frameworks like React. (The one big dependency we haven't removed is OpenCV.)