3 ms·
This seems to be the worst of both worlds. It's not easy for a human to read a square (compared to a line of text). The pixellated font is also not easily reada
by gnode 7y ago
This seems to be the worst of both worlds. It's not easy for a human to read a square (compared to a line of text). The pixellated font is also not easily readable compared to a vector font. It's also not easy for machines to read an optical coding with no spatially distributed redundancy.
QR codes and bar codes are brilliant for machines because misreads due to some spurious reflection or spec of dust is mitigated by error correction.
I feel like this problem is already well served by bar codes which have a human readable text representation below them (e.g. serial number stickers).
That said, I can see the security advantage of the computer reading the same representation as a human, although this is probably not the best place to enforce security. As there's no integrity check, there's little guarantee the computer will read what you see though. Maybe linear OCR combined with a barcode checksum would be a better way to achieve these goals.
- noobiemcfoob 7y agoThe problem this is addressing is a code being impenetrable by a human. If your solution is adding a second (human readable) code beneath the machine readable code...you haven't addressed the problem. The user must still trust their reader to parse the code. QR codes' reconstructability is a major strength that this lacks, but I'd bet there's a way to expand this to include ECC around it, much as QR codes can. BUT...OCR is quickly advancing, so the need for a specialized code a specialized machine can read will diminish over time anyway.
- gnode 7y agoAs I suggested at the end, you could still employ OCR and have a barcode checksum. The checksum would ensure a misread of the human readable text would fail. As long as the checksum was not error-correcting (so could not be engineered to augment a correct OCR read), it doesn't matter that it is incomprehensible to humans, because the OCR is authoritative. You could also implement the checksum as OCR-able text, although it wouldn't be as dense, and probably wouldn't help human readability. I think ultimately it should not be trusted that a machine will read what a code appears to be. That should be enforced on the device: "Are you sure you want to visit malware.site?". It's also easy to manipulate computer vision; you can engineer patterns which will read as one thing to humans, but another to machines. In some ways it's better for these codes to not be human readable, such that trust is not misplaced, and the machine is used as the best source of truth.
- deleted 7y ago[deleted]
- tinus_hn 7y agoQR codes strangely don’t have error correction, you just have to guess which bits are uncertain and try combinations until it matches the checksum. There is no formula you run which results in the original data.
- detaro 7y agoQR codes use Reed-Solomon codes for error correction, with various levels of error tolerance. This is very commonly used to place logos on top of the code and it still scanning correctly.
- tinus_hn 7y agoGuessing is still error correction of course. If you read the documentation you’ll find that practically Reed-Solomon code can’t correct errors if it doesn’t know which bits are uncertain. In the case of a QR code obviously the bits underneath the logo are uncertain. But if you just flip one bit it becomes much more difficult. I’m no expert in this but the I’ve read source code for several QR code readers and they don’t have some neat algorithm where you input the bits you read and it calculates the corrected bits. Perhaps something like that still exists, I’d be happy to see it.
- rkagerer 7y agoIt's interesting, but I agree not easy on human eyes. I think plain old text in a clear font, with an OCR reader than can lift URL's out of any text, would be nearly as effective and gain traction quicker. Feel free to rebut me!