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.
As 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.
The 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.
It'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!
The point isn't that it has flaws, but that its description is wrong. "Non-human eyes" -- normally understood to be OCR -- read it just fine. I think most of us were expecting something that disrupts "computer eyes" (e.g. because of deceiving overly narrow "tricks" that neural networks use to identify characters) but left it readable for the typical human (like an easy Captcha).
A more accurate (and helpful!) description of the problem you're solving is that this disrupts text parsers. That is, any program that just reads this in as text won't see the "real" letters (unless it's been pre-programmed with a specific reverser, etc.) and thus will frustrate, say, text search.
Which, on that note, I notice elsewhere you mention this being a solution applied to document submission in legal proceedings. In that case, the assumption might be that one side wishes to run text searches and assume its compatible with that. In that case, this could be viewed as non-compliance with a judge's orders, so FYI.
So the use case is primarily to produce something machine readable rather than human readable (it's not that unreadable, but still). I can see that. Is there a human-readable flag?
This is great work. But I don't understand the key point. Is this all to counterfeit OCR? By just using this font in my office program?
My gut feeling is that, given enough work, one can write some ML/AI algorithm to write OCR also for that font. But sure, the author states that this is also a symbolic work.
Bottom line: As long as a human can read the text, a computer will be able to do so, too.
We all know how hard CAPTCHAS got to solve (to us humans!) in the last year. We probably won't enjoy to read a multi paragraph captcha.
I think as far as culture goes it would be simpler to promote the idea that black bars are the only way to do it, than that you need to make sure you're using a special software that knows how to securely pixelate text.
It is a cool idea though, and text-shaped pixelation is much more satisfying than random noise. (And if someone's cheeky enough to decode it, they will be very disappointed ;)
Yeah the regular grid and text would probably make ocr even easier if it were necessary. It wouldn't surprise me if they just used uppercase letters, too.
Maybe they assumed that bots would interpret the page the way a human being would, when they're not looking at the source code? Though my money's on someone just not caring.
The issue is with OCR. Imagine something that was printed(for being physically signed or filed into a cabinet, for example) and rescanned into an image or PDF.
Both printing and scanning is lossy with lots of noise and artifacts.
The article is saying that serif fonts are harder to OCR.
But a rasterized text has a lot more information about each character than the raw ASCII values. If you halve the resolution or add compression artifacts an OCR will still pick it up.
If they rendered raw binary data they would have to add lots of redundant information as well as spreading it out over a large enough area. Maybe that's what you meant but didn't fit the 'trivially to do' part for me. Seems a lot easier to just render the text.
The answer is if a machine can't decode it, a human does.
One of my aunts worked as a postal worker for a while many years ago. She was hired for her ability to both read and type quickly. She reviewed addresses that couldn't be automatically recognized and did some sort of encoding that (I believe) generated that yellow printed barcode you see on some letters.
At least according to Atlas Obscura OCR has improved to the point that there's only one remote encoding site left and it's in Salt Lake City.
I'd avoid using this. This is a format that's lossy re: text, so text and numbers can get silently rewritten; it reuses a letter image, placing it throughout a page wherever it's recognized. A low resolution scan or bad ocr results in silently corrupted text.
i guess the lazy way to prevent this in a foolproof way is to add an ocr somewhere in the pipeline, and use actual images generated from websites. although maybe then you'll get #010101 text on a #000000 background
Very minor but interesting nitpick: the font used on checks is not OCR (optical) but MICR (magnetic ink). The design objectives are different and different font families exist for the two purposes. MICR as used on checks (more properly called E-13B) bears unusual, distinctive character shapes emphasizing abnormally wide horizontal components due to the need for each character to have a distinctive waveform when read as density from left to right, essentially by a tape recorder read head. Fonts optimized for OCR are usually more normal looking to humans because they emphasize clear detection of lines instead.
E-13B is a bit of an ideal use case for this method because of the highly constrained character set used on checks and the unusually nonuniform density of E-13B. The same thing can be done on text more generally but gets significantly more difficult.
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.
reply