I have worked in the space, making some strides in speed & error correction.
Some of my public work is here: https://austingwalters.com/chromatags/
Your best bet is actually an overlay of two codes. A regular image (for humans), plus a code embedded in a color space (see linked post for how to do that).
Doesn't the use of the latin alphabet act a bit like an error correction code here? In contrast to a pure binary code you know that only certain shapes are valid, which should allow you to do some guessing if you don't get a perfect match.
Edit: just found clicking go.to redirects to flock.com.
There still might be room for scams if the error correction is too clever, maybe it could only be a checksum?
Could the same technique be applied to QR codes? Would it improve QR read times?
At rush hour I have to wait for many people to scan their QR code train tickets, it is surprisingly slow.
I've actually improved it significantly since then, where it's possible to also store 2^8 data in something resembling a QR code, while keeping the same scanning speed as today.
 - https://en.wikipedia.org/wiki/Magnetic_ink_character_recogni...
 - https://en.wikipedia.org/wiki/OCR-A
For decades, I'd write out the amount field as:
So now I write $1234.29, and everyone is happy.
History wise it came about with the removal (or reduction) of check float when checks began to be processed electronically (turned into an ACH transaction with images of front & back being taken by the submitting bank). In the last TOS I read about check scanning what is actually happening is that your scanning of the check replaces the bank's scanning and they are using extracted data to create the ACH transaction. In the meantime they extend credit to you to match the amount they would normally advance you (varies by account and amount). It's been a while but I recall it being specifically credit as opposed to the usual 'available funds' at an ATM; this seems a distinction without a difference.
In the end - it's not secure or at least not much less secure than going to an ATM to deposit the check. The difference is that the ATM keeps the physical check for some small period of time such that if there is a problem with the ACH the bank might have physical possession of the check to assist in a fraud investigation (not that I think they'd need it as the law enabling electronic clearance I believe made the electronic images equivalent in all ways to the physical check).
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.
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.
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.
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.
If so, that’s an impressively fast prototype.
I haven't read that particular comment though. It is obvious that QR codes are a security concern. First, QR code readers are required to ask for permission to open URLs. They might as well not implement it or could have malicious codes for misrepresenting the URL in specific cases. Second, I wouldn't be surprised to see some bugs exploited in QR code scanning code by giving them strange codes to scan. These would not look like valid HR codes but would look like just another QR code.
So could an HR code reader. It could just as well, when it scans a google.com HR code, prompt "do you want to go to google.com" and then open "phishing.free.hax"
That specific threat is ridiculous.
In addition, talk of exploiting strange looking QR codes seems silly too. HR code readers could also have bugs in their OCR code which would result in memory corruption or such.
Any type of encoding can have interpreting tools that contain security bugs or malicious behaviour. The only way to remove that is to create something that is not intended to be processed by any tools at all (e.g. a paper that users have to manually copy the text from by hand).
That way, the detection of the URL will be more robust against dirt and damage, and the text can be displayed in a more ergonomic way (a QR code might be 5x5 cm, at two meters height, for example, making reading it by short humans with bad eyes a challenge)
Or are there use cases where the device reading QR codes doesn’t have a display?
By encoding possibly malicious URLs in QR codes and scanning them we try to mitigate the security concerns by having not enforced or even not specified requirements from the QR code clients. Such as a display, user prompt, a fitting typeface in the UI. All this could be optional with a solution like HR codes, with the added benefit of deciding whether to scan a code nor not by simply reading it first.
What _does_ help is just printing the URL in text, and requiring the user to type it in their browser’s address bar (assuming they trust their browser)
This is just a PoC of an idea I've created after reading https://news.ycombinator.com/item?id=21417026. But who knows, a human readable QR code alternative could born out of this.
When I looked up for this idea, I have found out http://hrqr.org/ but didn't find it much readable. Thanks to the comments here I came across OCR-A, OCR-B, and MICR just now. From these I've found Westminster typeface: http://luc.devroye.org/fonts-48273.html
Do you guys think using a font inspired by Westminster be a better choice than the prototype we have now?
In any case, the font should be resistant to malicious tampering such as creating an "o" from "c". Manual tampering could be also prevented with trailing checksum images that could be more information dense than the characters.
Error correction concern is the most common among the comments here. Yes, HR code readers would need to have error correction implementations to be reliable. Since each 7x7 grid of 2^49 binary options could only encode one of the 85 valid characters, HR codes could be recognized with even large chunks missing. On the other hand, implementations would be much more complex than the QR code error correction algorithm.
I reduced 3 corner blocks of QR codes to 1. This would make detection of HR codes much harder.
OCR, image recognition from video feed and average phone camera and processor has advanced so much in the past years that I think these technical costs could be favored for a human readable QR code alternative.
> If the app you are using to scan the QR code doesn't ask you for permission before opening the web page that's the problem with the app not the QR code...
You're right. If the protocol is not secure enough, then the layer above must be secured enough. But it's better to have the security at the protocol level. Here's the other reply of mine under this thread where I speculate about possible security issues with QR codes: https://news.ycombinator.com/item?id=21424988
I'm open for a better name than "HR code" by the way. It is too silly that makes it recognizable though.