Hacker News Reader

Hacker News

Comment by cyberax | Hacker News Reader

Parent Full thread

cyberax

My pet peeve:

WTF PEOPLE ARE NOT PUTTING A CLEAR TEXT URL NEXT TO THE QR CRAP?!?!?

Especially when the QR code itself points to a URL shortener.

View on HN

There’s no reason for it to be the same URL. It could be used to give a false sense of trust. Perhaps that’s why?

The QR scan/generate app I use always presents me the scanned data in text form and asks me to verify if I want to visit the URL or not. I don't know why anyone would chois an app that doesn't afford the user that basic level of control.

I use the Privacy Friendly QR Scanner, developed by a German university research group. More info available here: https://secuso.aifb.kit.edu/english/105.php

Indeed. I think these days that's also in the built-in scanners; certainly the QR code in this blog post no longer executes the embedded JavaScript when I scan it on my iPhone, though I'm sure it did back in 2017 when I wrote it:

https://kitsunesoftware.wordpress.com/2017/04/10/executable-...

I use the same one, installed via F-Droid (on Android 12). For me it can't adjust the focus of the camera, one has to open a camera app, adjust the focus, close camera, open QR app .. if you know of a fix then I'd be very happy.

If somebody can alter a restaurant's menu to point to a malicious site, they can just as well alter the QR code. Same goes for the payment information on a parking lot.

I don't think so. When you are drawing a poster, you don't necessarily think in terms of security. Most people drawing a poster are graphics designer, not security researcher. You think in terms of readability, convenience and esthetics. I don't think most people check the URL under a QR Code before flashing anyway.

Since most people don't type URLs themselves and can scan a QR code, it might not even occur to you that having the URL in plain text can be useful. It also takes space and it's not necessarily pretty.

(I do put the URL when making a visual with a QR Code, and require the URL to be there if I'm involved but not making the visual)

I think the forced tracking is half the point.

An example of this and candidate for worst use of a QR code is found on Wifi APs provided by AT&T. A sticker on the device shows a convenient QR code that will get you connected. If you're thinking it uses industry standard Wifi schema well you don't know AT&T very well. Instead it sends you to att.com. That's right, in order to connect to the wifi so you can get online you must first be online so you can get the password from a website.

Fortunately they still print the SSID and password on the back. But it's clear that AT&T would rather you go through their telemetry portal instead.

(And then there's how the signal on it was so weak that it couldn't penetrate interior walls more than 10 meters away. But that's another story.)

What forced tracking? If you're going to visit the URL, there is no extra tracking that can be provided by the QR or the shortener. Same if you aren't going to visit it

The QR code means that you can include a tracking id into the URL

My other pet peeve: Why don't QR scanner apps also just scan plain text URLs with simple OCR?

OCR works well on regular text because it can use language stats for error correction. On URLs?

Ping the URL in the background, if it returns a 404, iteratively change the least-confident character recognitions to the next best guess until it returns a 200 and then return that to the user. For example if it doesn't know whether a character is "I" or "l", and another character is a "0" or an "O", try all 4 combinations and show the correct one before the user even realizes.

If a piece of an URL looks like a word, factor that into your confidence scores as well, e.g. "somefoo.com/illusion/" is far more likely to be the correct URL, especially for something printed on paper, than "somefoo.com/iIIusion/", "somefoo.com/iIlusion/", or "somefoo.com/ilIusion/"

You don't even to do a full GET request, you can just use HEAD to save on mobile bandwidth.

For URLs that are printed on paper (e.g. at a restaurant table), have the backend do this and cache the correct URLs based on geolocation.

That's a pretty fragile and fault-prone method, and is extremely prone to typo squatting. I'm glad something like this isn't popular today, because it would very quickly be capitalized on by scammers, who wouldn't even have to rely on humans making typos anymore.

If it doesn't have error checking and checksums, it shouldn't be relied upon by the general public.

Why would typo squatting be part of the threat model?

Let's say you're at a restaurant, they have one of those stupid QR codes to view the menu (I really wish they would print the damn menus, but that's another story ...). Why not just an URL of "myrestaurant.com/menu" and you just scan that URL? Who would typo-squat an alternate menu and paste it on the restaurant tables?

If there's a venue in which typo-squatting is a potential threat, QR-squatting would be an even bigger threat because even if only 5% of people have sharp enough eyes to spot a typo squat, probably only 0.0001% of people are good at decoding QR codes in their brain and would spot a QR squat. The typo squat is easier to spot.

If you really wanted, we could also establish an optional checksum protocol for URLs e.g. http://myrestaurant.com/menu#cs=123

If the checksum fails, the phone can try (a) all possible 1-2 character edits for error correction, which should take only a couple milliseconds (b) auto-Google the URL to see if there is a fixed version of the URL (c) error out if both of the above fail.

They’re saying that an attacker would register variations of similar looking domains relying on the OCR misreading the correct URL. They aren’t suggesting that an attacker would paste the invalid URL in real life menus.

The whole point of QR codes is to paste URLs in real life. For non-real-life use cases even QR codes are unnecessary and people would just use links. For that, yes, typo-squatting and phishing are issues.

I'm suggesting that for real life we could just use URLs and OCR instead of QR codes.

> I'm suggesting that for real life we could just use URLs and OCR

No, because that's not reliable, and way more complicated and error-prone.

It's the same reason bar codes are used instead of directly the id they code.

Your earlier solution doesn't convince me. It's interesting, but not practical, and reading the URL should work even if internet is off or the server is down.

(Having a checksum next to the URL may start making OCR practical though)

Reply on news.ycombinator.com