Hacker News Reader

Comment by t_mann | Hacker News Reader

All of those could be done much more stealthily server-side, though, I don't get what the QR code modification would add here? Also, neither use case makes use of the hack described in the OP. Where I could see an attack based on that hack would be where an attacker plasters their code over a legitimate one. It would be kind of random which code gets read, so they could send some %-age of users to the original destination, hence possibly delaying detection. But it doesn't seem a given that this would compensate for the reduced traffic to their link.

View on HN

Some sort of MITM attack by someone who owns the display but not the server, maybe. Like a malicious ad company.

Ok, but then I'd still prefer a method that sends users to a unique URL. OP's method may help with obfuscating the changing of the code, but I'm sure there are ways to better achieve that without having to introduce this quasi-randomness. The simplest would probably be to just to regularly hide/show the code (which would happen anyway on a typical digital ad display that cycles through a number of ads).

But hypothetically, the owner of the ad might pop in and make sure

1. the ad looks correct, and

2. the URL is the one they expect

So there may be a use case for a QR code that looks almost identical but goes somewhere else, allowing them to swap it out while someone is looking at it without them realizing.

A niche use case, to be sure, but being able to exploit a niche vulnerability is a skill.

But if you own the display, you can send the user to whatever server you want.

> All of those could be done much more stealthily server-side, though, I don't get what the QR code modification would add here?

Even if the adversary controls the server side as well, you need to tell the server the information needed to make a decision If you control everything that is easy enough too, but perhaps you want to keep the decision-making process local – for plausible deniability server-side, just to reduce server & bandwidth load, or because you are sending people to completely different destinations not just altering link parameters.

Replacing the QR code more statically sends everyone to the new address, not just the target(s), altering the QR code by a bit or two (and the relevant error correction bits too) in response to a pile of information available at the QR reading site (feeds from cameras, and such) would be how the server knows to react differently without having access to that collection of information itself. You might want to use some clever analysis to minimise the visual effect if you are altering the QR code while it is already displayed – the two examples here look very different, but the change could be much more subtle. If sending to very different destinations, so the codes for the URLs will look very different, then adding a link anonymiser between would keep the change minimal.

> Also, neither use case makes use of the hack described in the OP.

True.

Reply on news.ycombinator.com