14 ms·
Show HN: HR code – Designed to be recognized by humans and OCR
- KenanSulayman 7y agoThe biggest win with QR codes is their error recovery capability, though. This will just corrupt data if there's errors.
- fbrchps 7y agoIf OCR is required, then why not just put the link in plaintext? Makes it even easier to be read by humans.
- suyash 7y agoThat would be the next logical evolution from QR code once CV becomes more accurate for reading plaintext.
- wfdctrl 7y agoIf 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...
- suyash 7y agoMost QR codes are use to open a website and you do get a prompt for that at least on iOS so I don't see an issue there.
- gnode 7y agoThis 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
- badgers 7y agoThis reminds me of the E-13B font [1] seen on checks since the early 1960s, but in a square format. The goals are similar, produce machine readable and human readable text. There have been attempts to also make a version with alphabetical characters as well in OCR-A [2] in the late 1960s. [1] - https://en.wikipedia.org/wiki/Magnetic_ink_character_recognition https://en.wikipedia.org/wiki/Magnetic_ink_character_recogni... [2] - https://en.wikipedia.org/wiki/OCR-A https://en.wikipedia.org/wiki/OCR-A
- Merrill 7y agoChecks are now often scanned optically, with the MICR line, the courtesy amount field and the legal amount field all being read by software character and handwriting recognition. There is a small security deficit, since a fraudulent check with a non-magnetic MICR line would not be detected.
- mNovak 7y agoSince it came up.. I've always wondered how mobile deposit (cell phone photo of a check) is remotely secure?
- nathancahill 7y agoIt's not. But you're required to keep a copy of the check after you scan it.
- velosol 7y agoIt's nearly as secure as going to the ATM to deposit the check and most banks are OK with the increased risk because they have extra identifiers (phone/app info) when you 'scan' the check. Which is to say the whole process is not terribly secure. 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).
- citilife 7y agoThe problem with this is that it's prone to error (doesn't have error correcting bits). Unfortunately, that combined with speed of scanning is really what's key for codes. I have worked in the space, making some strides in speed & error correction. Some of my public work is here: https://austingwalters.com/chromatags/ 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).
- avian 7y ago> The problem with this is that it's prone to error (doesn't have error correcting bits 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.
- jakear 7y agoDoesn’t help if a whole cell is missing, whereas with QR codes chunks can be entirely gone without consequence.
- pause_break 7y agoCan you give some practical examples of where that would be useful? Honestly curious, don't know much about this space.
- Xeago 7y agoA lot of applications centralize their logo in a QR code, obscuring a significant chunk. Yet the code scans fine and there is some nice custom recognizability for which service it is.
- wingerlang 7y agoMaybe scanning from photos where the code is obscured, bad quality, almost-trashed physical codes.
- loa_in_ 7y agoSome characters can be easily turned into others - c into o, C into D - by addition. I think it would be a good idea to make priors have an additional pixel or two to the font glyphs to make this impossible. Maybe even touching the border instead of the character.
- la_fayette 7y agoThe qr code has three distinctive squares on the corners, which makes detection in images accurate. However, the proposed approach is missing that feature. Thats why I wouldn't call it an easy ocr problem, more like scene text detection, which is acctually a hard problem.
- deleted 7y ago[deleted]
- tobr 7y agoI need to ask, is this in response to the discussion in [1]? I see that the initial commit happened after that discussion started. If so, that’s an impressively fast prototype. 1: https://news.ycombinator.com/item?id=21417433 https://news.ycombinator.com/item?id=21417433
- emrehan 7y agoYes, I've made this after reading the post. Thanks. 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.
- TheDong 7y ago> QR code readers ... could have malicious codes for misrepresenting the URL in specific cases. 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).
- jolmg 7y agoI wonder if there's a font with the same idea of being easy to OCR. I mean something that one can write full pages of and be easy to read for both the human and the machine.
- mfkp 7y agoThat's probably https://en.wikipedia.org/wiki/OCR-B https://en.wikipedia.org/wiki/OCR-B - developed in the 1960s. (OCR-A might be more common but I'd say less human readable).
- jolmg 7y agoInteresting. I was expecting something with more machine visual aids, like square markers to easily determine the start, size, and angle of the text. I wouldn't be able to guess that this font was designed for OCR. I wonder what design considerations they took. From the look at the applications, maybe they assumed perfect/consistent reading conditions, instead of e.g. a casual photo of the text with little consideration to alignment or using a prepared format.
- joshdance 7y agoI like the idea. Having symbols is hard because you have to know the generally accepted name for that symbol in order to tell it to someone.
- breck 7y agoThis is awesome! Feels like there's a kernel of a very interesting idea here. Could see how this evolves into a successor for QR codes. Looking forward to see where it goes.
- mark-r 7y agoWhat problem does this solve that MICR couldn't do better?
- mlindner 7y agoThe name is bad. "HR code" is immediately associated in my mind with "HR" as in Human Resources. You should pick a better name.
- jolmg 7y agoIndeed, I had the same expectation that it was something related to Human Resources, and it's not like the H replaced a word that means "machine" or anything. It could have been "HQR code".
- sytse 7y agoIs it possible to make a valid QR code that is human readable by manipulating the size, weight, greyscale?, and positioning of letters?
- emrehan 7y agoWow, I didn't expect this post to have any traction. Many thanks for the diverse feedback. This is just a PoC of an idea I've created after reading https://news.ycombinator.com/item?id=21417026 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/ 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 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... (wfdctrl's comment) 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 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.
- aabbcc1241 7y agoThe font and the way to break words is not quite human readable IMO …
- gouggoug 7y agoI guess the keyword here is "recognizable". The goal isn't to make it extremely readable, but make it both readable by a machine and sufficiently readable by a human.
- ecesena 7y agoThis is pretty awesome! I just read a related thread on HN a few hours ago on this very issue, so big kudos for the time of execution.
- Someone 7y agoIMO, the easier and better solution would be for your device to pop up a ”Open <URL>?” alert. 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?
- emrehan 7y agoUser confirmation is a feature in most of the QR code readers. But it’s an optional feature. We are also depending on QR code scanners not to use an ambiguous font for URLs or misrepresent URLs in certain cases maliciously. 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.
- Someone 7y agoBut making QR code’s readable by users doesn’t protect against that. Whatever the QR code looks like, you have to trust the scanner. It could open “evil.com” every tenth time you use it, roll a die to determine whether to do so, contact its host to ask ”user u scanned QR code q. What URL shall I open?”, run a quick auction for the URL to send the user to, etc. 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)