The best thing about QR codes is that they're free. It doesn't cost any money to generate one. They're an open standard with no middle-men. Users can go direct to your site!

Except… Some people want to insert themselves into your conversation. Sometimes it is for malicious reasons, sometimes it is greed for user data, and sometimes it is just incompetence.

Let's take this example - a health centre wants people to register. Scan the QR and get started. Fab!

Photo shamelessly stolen from a LinkedIn contact.

But what happens when you scan the QR code? Rather than taking you directly to an authoritative and trusted NHS.UK domain name, it sends you through https://register-with-gp.ht1.uk/.

Who on earth are HT1.UK?

According to their website, they're an automation company who are "on a mission to make the NHS the most advanced healthcare system in the world."

Good for them. But what information are they collecting about users who traverse through their QR codes? If you take a look at their privacy policy you won't find anything specific. Never mind, let's email their friendly privacy team. What's their email address?

Of course, emailing that gets you back this error:

Emoji! How fun!!

So I emailed the new address to see what information they were collecting. Their response wasn't particularly informative.

because Healthtech-1 is a processor of information and the GP practice is the data controller any requests about how your data is handled should be made to the GP practice who can inform you of the information you requested.

…

I can confirm that there is no information stored about users who scan the QR codes and no cookies placed.

But, of course, users have no way of verifying what this company is storing about them. There's simply no reason to use an untrusted 3rd party like this to provide either a QR code or an intermediary website.

Why this is a problem

Trust is everything. People are constantly being scammed. One of the great things that GOV.UK did was to say "This here is our trusted brand. If you don't see GOV.UK in the URl bar - don't trust it!"

The NHS should be doing the same. Every hospital, surgery, and clinic should have an NHS.UK domain name. When a user sees a link to a healthcare service which doesn't go through NHS.UK, they should feel suspicious and not click on it.

There is no way as a regular user to know that HT1.UK is a trusted domain. What about HT1.biz? HT2.UK? NHS.info.ly? What happens if HT1 go bust or have their domain name hijacked?

The NHS must stop the proliferation of these 3rd party domain names. They need to reinforce users' understanding that NHS.UK is the only trusted domain name for official NHS services.

I'm sure HT1.UK aren't doing anything nefarious with the data of people who visit their QR codes. I'm sure they're not inserting tracking cookies or selling my data. But I shouldn't have to be sure. All users should be pointed directly to an NHS.UK domain without having to risk whether their details are going via a dodgy site.

Here endeth the rant.

I've been thinking about fun little artistic things to do with QR codes. What if each individual pixel were a QR code?

There's two fundamental problems with that idea. Firstly, a QR code needs whitespace around it in order to be scanned properly.

So I focussed on the top left positional marker. There's plenty of whitespace there.

Secondly, because QR codes contain a lot of white pixels inside them, scaling down the code usually results in a grey square - which is unlikely to be recognised as a black pixel when scanning.

So I cheated! I made the smaller code transparent and gradually increased its opacity as it grows larger.

I took a Version 2 QR code - which is 25px wide. With a 2px whitespace border around it, that makes 29px * 29px.

Blow it up to 2900px * 2900px. That will be the base image.

Take the original 25px code and blow it up to the size of the new marker, 300px * 300px. Place it on a new transparent canvas the size of the base image, and place it where the marker is - 400px from the top and left.

Next step is creating the image sequence for zooming in. The aim is to move in to the target area, then directly zoom in.

The whole code, if you want to build one yourself, is:

#!/bin/bash

#   Input file
input="25.png"

#   Add a whitespace border
convert "$input" -bordercolor white -border 2 29.png

#   Upscaled image size
upscaled_size=2900

#   Scale it up for the base
convert 29.png -scale "${upscaled_size}x${upscaled_size}"\! base.png

#   Create the overlay
convert -size "${upscaled_size}x${upscaled_size}" xc:none canvas.png
convert "$input" -scale 300x300\! 300.png
convert canvas.png 300.png -geometry +400+400 -composite overlay.png

#   Start crop size (full image) and end crop size (target region)
start_crop=$upscaled_size
end_crop=350

#   Zoom-in target position (top-left corner)
target_x=375
target_y=375

#   Start with a completely opaque image
original_opacity=0

#   Number of intermediate images
steps=100

for i in $(seq 0 $((steps - 1))); do
    #   Calculate current crop size
    crop_size=$(echo "$start_crop - ($start_crop - $end_crop) * $i / ($steps - 1)" | bc)
    crop_size=$(printf "%.0f" "$crop_size")  # Round to nearest integer

    #   Keep zoom centered on the target
    crop_x_offset=$(echo "$target_x - ($crop_size - $end_crop) / 2" | bc)
    crop_y_offset=$(echo "$target_y - ($crop_size - $end_crop) / 2" | bc)

    #   Once centred, zoom in normally
    if (( crop_x_offset < 0 )); then crop_x_offset=0; fi
    if (( crop_y_offset < 0 )); then crop_y_offset=0; fi

    #   Generate output filenames
    background_file=$(printf "%s_%03d.png" "background" "$i")
    overlay_file=$(printf "%s_%03d.png" "overlay" "$i")
    combined_file=$(printf "%s_%03d.png" "combined" "$i")

    #   Crop and resize the base
    convert "base.png" -crop "${crop_size}x${crop_size}+${crop_x_offset}+${crop_y_offset}" \
            -resize "${upscaled_size}x${upscaled_size}" \
            "$background_file"

    #   Transparancy for the overlay
    opacity=$(echo "$original_opacity + 0.01 * $i" | bc)

    # Crop and resize the overlay
    convert "overlay.png" -alpha on -channel A -evaluate multiply "$opacity" \
            -crop "${crop_size}x${crop_size}+${crop_x_offset}+${crop_y_offset}" \
            -resize "${upscaled_size}x${upscaled_size}" \
            "$overlay_file"

    #   Combine the two files
    convert "$background_file" "$overlay_file" -composite "$combined_file"
done

#   Create a 25fps video, scaled to 1024px
ffmpeg -framerate 25 -i combined_%03d.png -vf "scale=1024:1024" -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p recursive.mp4

Left is upper-case HTTPS://EDENT.TEL/ and right is lower-case https://edent.tel/

You can clearly see that the one on the left is a "smaller" QR as it has fewer bits of data in it. Both go to the same URl, the only difference is the casing.

What's going on?

Your first thought might be that there's a different level of error-correction. QR codes can have increasing levels of redundancy in order to make sure they can be scanned when damaged. But, in this case, they both have Low error correction.

The smaller code is "Type 1" - it is 21px * 21px. The larger is "Type 2" with 25px * 25px.

The official specification describes the versions in more details. The smaller code should be able to hold 25 alphanumeric character. But https://edent.tel/ is only 18 characters long. So why is it bumped into a larger code?

Using a decoder like ZXING it is possible to see the raw bytes of each code.

UPPER

20 93 1a a6 54 63 dd 28   
35 1b 50 e9 3b dc 00 ec
11 ec 11 

lower:

41 26 87 47 47 07 33 a2   
f2 f6 56 46 56 e7 42 e7
46 56 c2 f0 ec 11 ec 11   
ec 11 ec 11 ec 11 ec 11
ec 11 

You might have noticed that they both end with the same sequence: ec 11 Those are "padding bytes" because the data needs to completely fill the QR code. But - hang on! - not only does the UPPER one safely contain the text, it also has some spare padding?

The answer lies in the first couple of bytes.

Once the raw bytes have been read, a QR scanner needs to know exactly what sort of code it is dealing with. The first four bits tell it the mode. Let's convert the hex to binary and then split after the first four bits:

The UPPER code is 0010 which indicates it is Alphanumeric - the standard says the next 9 bits show the length of data.

The lower code is 0100 which indicates it is Byte mode - the standard says the next 8 bits show the length of data.

Look at that! They both have a length of 10010 which, converted to binary, is 18 - the exact length of the text.

Alphanumeric users 11 bits for every two characters, Byte mode uses (you guessed it!) 8 bits per single character.

But why is the lower-case code pushed into Byte mode? Isn't it using letters and number?

Well, yes. But in order to store data efficiently, Alphanumeric mode only has a limited subset of characters available. Upper-case letters, and a handful of punctuation symbols: space $ % * + - . / :

Luckily, that's enough for a protocol, domain, and path. Sadly, no GET parameters.

So, there you have it. If you want the smallest possible physical size for a QR code which contains a URl, make sure the text is all in capital letters.

This blog post was exhibited at QR Show, NYC

When I first wrote about QR Hijacking in 2011, I said that such attacks were usually easy to spot:

Recently, a new wave of QR Hijacking attacks have been reported in Bournemouth:

A further warning about fake QR codes on parking ticket machines has been issued after new stickers were found in numerous beach resort car parks.

When scanned the codes go to a fraudulent website.

Further warning over fake parking QR code scam - BBC News

Let's take a look at some photos of the attacks. Then I'll explain how to prevent them.

First up, this photo from Bournemouth, Christchurch and Poole Council's Facebook page:

These are pretty crappy attempts! The original code in the top right corner has been covered, which might fool some people. However, it is pooly aligned and sized. The other code is sloppily placed in the middle of the text. It doesn't look convincing. While the codes may have looked legitimate when first placed on, ten minutes in the English rain makes it apparent that they are paper forgeries.

And then there's this QR code randomly stuck on to a parking machine:

The URl it goes to is superficially convincing - fee-parking-pay.info - but let's take a closer look:

It has been inexpertly cut out, it is too large for the space provided, and is clearly stuck on. Rubbish!

Finally, there's this sticker found by Bournemouth Police:

This one is much harder to spot! It's about the right size and shape. It looks well aligned and the paper hasn't degraded. But do you notice what's printed above it? The official URl. And that leads me on to…

How to Prevent QR Code Hijacking

Putting QR codes behind a glass screen isn't always practical, and reflections in the glass can make it hard to scan a code. It's difficult to make a code physically inaccessible for a scammer while also making it easy to scan.

The number one thing to do is display the official URl nearby.

Every QR scanner that I know shows you the URl before opening the page. Every web browser shows you the full URl of the site you're on.

If someone scans a code which goes to totally-official-parking.biz but they can see the parking sign says pay4parking.gov.uk then they are much less likely to fall for the scam.

You can do fancy things like incorporate a logo into you QR, or print it on a coloured background, or have people regularly check your codes for signs of tampering. Those might keep your users secure, but can be bypassed by a sufficiently determined attacker.

A large printed URl isn't infallible, but it is much harder for an attacker to deface a large area of a poster than it is to cover a small QR square.

As for what to do if you're worried about the legitimacy of these codes:

Anyone worried about paying online for parking can also pay by debit card/contactless or cash at a parking meter.

BCP Council

As I've mentioned before, the TOTP specification is a stagnant wasteland. But it does have this to say about the secret:

The secret parameter is an arbitrary key value encoded in Base32 according to RFC 3548.

The Base32 alphabet is pretty simple. The upper-case letters A - Z, and the numbers 3 - 7.

But that's only half the problem.

How long should the secret be?

This is an area where the official spec is silent. Around the web, you'll find people saying things like:

The length in bytes of generated shared secrets. The minimum is 20 (or 160 bits), and the default is 32 (or 256 bits). In most use cases 32 is sufficient. Though some authenticators may have issues with more than the minimum. Our minimum is the recommended value in RFC4226, though technically according to the specification 16 bytes (or 128 bits) is the minimum. Authelia

Although that's for the HOTP algorithm, rather than TOTP.

Looking through my 49(!) different TOTP codes, the shared secret ranges from 16 characters to 52 characters. No consistency whatsoever.

The Code

Run this on your command line.

cat /dev/urandom | LC_ALL=C tr -dc 'A-Z3-7' | fold -w 24 | head -n 1

That generates a random-enough⁰ string using the correct alphabet and truncated to a sensible length.

Let's go through each part of it.

cat /dev/urandom spits out random data from your machine. You may wish to use /dev/random if you feel like it.

LC_ALL=C sets the Locale to by ANSI bytes.

tr is "Translate, squeeze, and/or delete characters.".

-dc 'A-Z3-7' is delete the complement (i.e. delete anything which isn't in the following string).

fold -w 24 is wrap the input text with a line length of 24.

head -n 1 displays the first line of the file.

Next Steps

Now... How do I locally generate a QR code without anything else being installed...?

When you scan a 2FA token into your authenticator app via QR code, you get presented with a bunch of information about your account. This lets you store things like the issuer and the account name.

I recently scanned a code, and it displayed my name as Terence+Eden. Which was a bit weird. Try it yourself:

Checking the raw output of the code, shows the underlying data is:

otpauth://totp/
   Private%20Bank%20Account:
      Your+Name+Here?
         secret=abcdefghijklmno&
         digits=6&
         issuer=Cayman%20Island%20Bank&
         algorithm=SHA1&
         period=30

The One Time Password information is encoded as a URl. Generally speaking, a URl cannot contain spaces. So they get encoded. But how should they be encoded?

The HTML specification, RFC1866, talks about when a space should be encoded as +.

The form field names and values are escaped: space characters are replaced by +, and then reserved characters are escaped … that is, non-alphanumeric characters are replaced by %HH

8.2.1. The form-urlencoded Media Type

That is, a space becomes a plus only when it is submitted as part of a form. Not as part of a GET request.

This is slightly confused by a later section:

The keywords are escaped according … and joined by +. For example … the user provides the keywords apple and berry, then the user agent must access the resource

http://host/index?apple+berry ? 7.5. Queries and Indexes

But, in the case of OTP, the user's name is not multiple keywords. It is a single datum.

So it should use %20, that's pretty obvious - right?

Well… not quite. You'll find many people (correctly) saying that path fragment of a URl doesn't have to be percent encoded.

This example is perfectly valid:

https://example.com/My+Cool+Page.php?username=Terence%20Eden

And, as we can see in the above optauth scheme, the user's name does come before the ?!

OK, let's take a look at the OTP scheme standard. The original is an archived Github page from Google.

The label is used to identify which account a key is associated with. It contains an account name, which is a URI-encoded string, optionally prefixed by an issuer string identifying the provider or service managing that account.

So that gives us Issuer:Name. But, as we've seen above "URI-encoded" is a little ambiguous. It goes on to say "optional spaces may precede the account name" and gives the ABNF as label = accountname / issuer (“:” / “%3A”) *”%20” accountname

But, again, that doesn't say anything about how spaces inside the account name should be encoded.

Finally, it gives some non-normative examples, including: Provider1:Alice%20Smith which shows a space being percent encoded.

Summary

The confusion arises, I think, because the label is not part of the query string. If it were, it would be obvious that it should have percent encoding applied to it.

But because it appears before the ?, it looks like it is part of the pathname. Therefore, some encoding libraries - and some humans - get a little confused.

I contacted a few organisations who had made this mistake - and they were quick to fix it.

I want to play around with 2FA codes. So, I started looking for the specification. Turns out, there isn't one. Not really.

IANA has a provisional registration - but no spec.

It links to an archived Google Wiki which, as we'll come on to, isn't sufficient.

There's some documentation from Yubico which is mostly a copy of the Google wiki with some incompatible tweaks.

The Internet Initiative Japan has a subtly different spec which includes an icon parameter not seen in any other.

Hidden halfway down the IETF tracker for Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication is yet another specification which is incompatible with the others!

Oh, and IBM has yet another one!

Of course, Apple have their own special Apple-specific version. It is identical to Google's, but uses the apple-otpauth: scheme. Because.

Here's a quick table comparing them:

I tried creating a variety of codes on the fringes of the specification - more than 8 digits, lower than 15 second periods, weird issuers - to see what would happen if my trusting friends scanned them with their TOTP apps.

Sam Nalty

@samnalty

Replying to @kerguio@kerguio @edent Weird, worked for me on 1password for android

---

Sam Nalty

@samnalty

Replying to @samnalty@kerguio @edent Even weirder, in the Android app it is a 10 digit OTP but on the windows app it's a normal 6 digit one.

---

Ben Nuttall

@ben_nuttall

Replying to @edent@edent Seems to work as my others do (in Google Authenticator), apart from the name is emojis and some RTL text

---

Serge

@kerguio

Replying to @edent@edent Keychain in iOS seemed to ingest it, but not sure where it went...

---

John

@Johninnit

Replying to @edent@edent Authy says "Token format invalid"

---

Why is this a problem?

Formally standardised specifications are a good thing. They mean that everyone is on a level playing-field and innovation can happen without actors enclosing the commons.

More prosaically, it means that users can be confident that any app will work with any code from any provider. And implementers can have a forum where they can propose enhancements to the spec which won't break users' devices.

Where are the specifications deficient?

The URI encoding trips up a number of publishers - more on that in a later blog post.

Should there be a maximum or minimum length to the secret? Why? Why not?

Is it a wise idea to fix those algorithms? Does it matter if a weaker one is in there? Can they be deprecated?

Why just 6 or 8 digits? What's wrong with an arbitrary number of digits? What about using letters or other symbols?

The period is in seconds. Does that mean whole seconds? Can users reliably type in 8 digit codes which change every 15 seconds?

"Issuer" is in there twice. What if they don't match each other?

Do users want an "icon"? Should it be a Base64 encoded graphic? If so, what format? If not, is a URL sufficient?

I'm sure there are half-a-dozen more gripes you could come up with.

The future kinda sucks

I am so tired of Google getting bored halfway through designing something - and then expecting the rest of us to just figure out what they meant.

We're now in a situation where everyone is (rightly) pushing TOTP for 2FA, but there's no formal specification for how users can scan those codes into their apps. There's no way to propose changes. And there's no guarantee that a user will be able to reliably scan the codes they are given.

Bad times.

Search back through this blog and you'll find dozens of posts about QR codes. Back in the day, I was a freelance "Mobile Internet" consultant. I'd rock up to companies and say "you know you can get the Web on your phone, right? It's going to be the next big thing!" And people would pay me handsomely for that advice.

I'd also talk about apps - "You don't need one, but if you're going to develop one, here's what you need to know." It was like pushing on an open door.

My final pitch was always - "Hey, QR codes are pretty nifty! Would you like some help with them?"

Silence. Followed by a swift refusal.

The arguments against QR codes back then fell into a few main categories

• They're ugly (true, but they can be made prettier)
• People don't scan them (false, with lots of data)
• Hackers might do something bad (unlikely, and easily defended against)

But, the main objection was that QR codes could never succeed because no one could make money from them!

This was a time when Microsoft was pushing its paid-for MS Tag product - which only lasted about 3 years before it was shut down. They were trying to capture the mobile code scanning market, and failed.

Although lots of people were building scanners, there were very few companies pushing QR codes because they couldn't see a way to make money from them. Sure, there were a few companies which would sell you a short URL with analytics baked in. But there was no "moat". Anyone could build a slightly cheaper competitor. And businesses could bypass those companies easily. With no commercial driver, there was no pressure to promote the use of QR. So - in the UK at least - QR codes bumbled along, occasionally appearing on energy bills, physical products, and informational posters.

The "problem" is that QR codes are "boring infrastructure". That's what makes them magical - they're both libre and gratis.

Libre because QR codes are free to create - there are no royalties, 3rd parties, nor approval processes.

Gratis because QR codes are too cheap. They only cost black ink. They are so cheap, you can stick them on a sachets of salt and pepper! Try doing that with an NFC!

I was told that without organisations trying to drive adoption - whether to gain a monopoly or to drive people to walled-gardens - QR codes would never gain popularity.

I think that was true - up to a point. QR codes were always more popular with people than they were with advertisers.

But, in the end, it is somewhat gratifying being proven right. Mostly. It is great seeing restaurants using QR codes on their daily menus. And most product manuals, adverts, and fliers now contain a code. We're not there with payments - not in the same way China is. I kinda wish I'd finished writing my book about QR codes in 2014!

I was lucky enough to be in the right place at the right time to help the NHS with their QR check-in for COVID security. Which was nice. I just wish it didn't take a pandemic to make QR codes this popular!

Terence Eden is on Mastodon

@edent

Me in 2007: 🤔 Wouldn't it be neat if QR Codes were everywhere?

Me in 2020: 😢 Wouldn't it be neat if we didn't need QR Codes at the entrance to every shop.

Terence Eden is on Mastodon

@edent

Turns out, I've been blogging about QR codes for 4 years.
shkspr.mobi/blog/index.php…

---

---

⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️
⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️⬜️⬜️⬛️⬜️⬜️⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️
⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬛️⬜️⬛️⬛️⬜️⬛️⬛️⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬛️⬜️
⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬜️⬛️⬜️⬛️⬛️⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️
⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬛️⬜️⬛️⬛️⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️
⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬜️⬜️⬛️⬜️⬜️⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️
⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬛️⬜️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬛️⬜️
⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬜️⬛️⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️
⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬛️⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️
⬜️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬛️⬛️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬜️⬛️⬜️⬜️
⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬜️
⬜️⬛️⬛️⬜️⬜️⬜️⬜️⬛️⬛️⬜️⬜️⬛️⬛️⬛️⬛️⬜️⬜️⬜️⬜️⬛️⬛️⬜️⬜️
⬜️⬛️⬜️⬜️⬜️⬜️⬛️⬜️⬜️⬛️⬛️⬜️⬜️⬜️⬛️⬜️⬜️⬛️⬛️⬛️⬜️⬜️⬜️
⬜️⬜️⬛️⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️⬜️⬛️⬜️⬛️⬛️⬜️⬜️⬛️⬜️
⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬛️⬛️⬜️⬜️⬜️⬛️⬜️⬛️⬛️⬛️⬛️⬜️⬛️⬜️
⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬜️⬜️⬜️⬛️⬜️⬜️⬛️⬜️⬜️⬛️⬛️⬜️⬜️
⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬛️⬜️⬜️⬛️⬛️⬜️⬛️⬛️⬜️⬜️⬛️⬛️⬛️⬜️⬜️⬜️
⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬛️⬜️⬜️⬜️⬜️
⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬜️⬜️⬛️⬜️⬛️⬜️⬛️⬛️⬜️⬛️⬛️⬜️⬜️
⬜️⬛️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬛️⬜️⬜️⬛️⬛️⬛️⬜️⬛️⬜️⬜️⬛️⬜️⬜️⬜️
⬜️⬛️⬜️⬜️⬜️⬜️⬜️⬛️⬜️⬛️⬛️⬜️⬜️⬜️⬛️⬜️⬛️⬛️⬜️⬛️⬜️⬜️⬜️
⬜️⬛️⬛️⬛️⬛️⬛️⬛️⬛️⬜️⬛️⬛️⬜️⬛️⬜️⬜️⬛️⬛️⬛️⬛️⬜️⬛️⬜️⬜️
⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️⬜️

How?

There are lots of ASCII block characters, but none are specifically marked as white / empty. Additionally, some fonts don't make the characters pure squares.

There are two characters which, generally, render as square Emoji:

• Unicode character U+2B1B is a large black square ⬛ .
• Unicode character U+2B1C is a large white square ⬜ .

These characters are from the Unicode block "Geometric Shapes". When paired with ️Variation Selector-16, they are given an Emoji presentation.

The above QR code is styled with "line-height:1em;" to make sure there are no vertical gaps between characters, and "letter-spacing:-3px;" to squash any horizontal gaps.

I found that it scanned reliably on my devices.

Why?

I was having a discussion with someone about the limitations of text based communication. How do you send a QR in, say, an email when you aren't allowed to attach anything? We were looking at a text only system which wouldn't allow attachments or BASE64 encoded inline.

So I knocked up a quick scrap of code to see if it would work with Emoji. It sort of works - but only if you can control the exact layout. On mobile screens, it might be too narrow, and you can't easily control the character spacing.

So, a nice idea, but a little pointless!

Can I tweet that??!?

The smallest possible QR code is 21x21 pixels, that's too many characters to fit into a Tweet. Sorry!

You can post it on something like Mastodon but without the fine-grained CSS control, it probably won't be readable.

Whether you're rich, poor, British, foreign, young, old - you can enjoy the treasures of our museums and galleries.

Of course, while museums are funded by the state, they still rely on generating some external revenue - hence the ubiquitous gift shop and major corporate donations.

In the front of most museums, you'll find a vessel for collecting donations. Usually half full with pound coins, Euros, and Dollars. On entering the British Museum recently, I saw a new way to donate - QR codes!

Let's take a closer look at that code:

If you scan it, your QR reader should prompt you to send a Premium Rate SMS to 70070 - a charity donation service run by Just Giving.

Just about anyone with a UK SIM will be able to send a fiver - no messing about with passwords, logging in, credit card numbers - it comes straight off the phone bill.

Setting It Up

It's really very easy to use the SMS feature of QR codes. Assuming you've already got a number which can receive messages, you simply need to enter this text into your QR code:

SMSTO:07700900617:Hello

Which will appear as:

Scan it and you QR scanner should open up your SMS app, and you can choose whether to send or not.

So, there you go! A really simple way to turn QR codes into donations using the ubiquitous SMS.

Errr.... yes... It's pretty damn simple! I was surprised I couldn't find anyone else doing this.

 (\_/)
(='.'=)
(")_(")

Becomes:

Which, when scanned, renders as:

Now, there are limits as to what you can put into a QR code - about 4,000 characters. Different devices have different screen widths, which limits the ability to include fully featured ASCII Artworks like the Mona Lisa

Well, we can finally unwrap one of the little projects The Lab has been working on. Along with the Department of Energy and Climate Change we're aiming to stick QR codes on customers' energy bills.

The proposal has the grand name of: "A consultation on proposals to amend domestic energy supply licence conditions - requiring provision of key energy data in a machine readable format"

How Will It Work?

Customers will receive their energy bill as normal. Printed on the bill will be a QR code which lets the customer compare their usage, get energy efficiency advice, and potentially switch to a cheaper tariff.

You can read more on BBC News, The Guardian, Sky News, ITV News, MarketingWeek, The Drum and City AM.

This project has been gestating for a while - being first mentioned in the House of Commons in October 2012 - and is now being empowered via the Energy Act.

This is the first time The Lab has helped with such a stately project - and we certainly hope to do more of this sort of work in the future.

What Next?

We know that QR codes are divisive for some - but they remain the cheapest way to put complex information on a piece of paper. They don't require a proprietary app, and can be used even on really quite basic phones.

We'd love it if you were to respond to the consultation.

Credits

Terence Eden led this project, along with Lab Intern Yuan Phoon.

Terence Eden is on Mastodon

@edent

OMG! Reading "Inside the Nudge Unit" by David Halpern - and it mentions the QR energy project I worked on when I was at O2 😀

blog.lab-cloud.net/2014/03/Lets-P…
blog.lab-cloud.net/2014/03/QR-Cod… pic.x.com/sg3tv9pvuz

---

It's always nice when other companies imitate your success - and it's always amusing when they fall slightly short of the mark.

Lots of items in stores have QR codes on them. There's a limit to how much information you can cram onto packaging. It gives the customers more information, helps them buy the right product, and reduces the number of questions they ask a sales assistant. QR FTW?

If you look closely at the above package, you'll see a QR nestled in the corner. Sadly, the plastic around is is deforming it. This, of course, renders the code completely unscanable.

If you need help with your QR code, follow my 10 simple steps for perfect QR codes, or if you need some bespoke consultancy give me a call.

Their terms and conditions at the time said

We will also use commercially reasonable efforts to make these basic features available until at least January 1, 2015, and provide two years prior notice before we terminate the basic features or the entire Microsoft Tag service.

Well, they've just given their two years' notice. They've offloaded the entire service off to ScanBuy:

Through August 19, 2015, you will be able to continue to log into your existing Microsoft Tag service account, use existing Microsoft Tag codes, generate new Microsoft Tags, and run reports as usual. Scanbuy plans to support Microsoft Tag Technology on the ScanLife platform beginning no later than September 18th, 2013, and to offer transition and migration services to Microsoft Tag customers who choose to migrate to the ScanLife platform.

I've got nothing against ScanBuy - but why would anyone carry on with this ridiculous platform now? What's to stop ScanBuy in the future abandoning it, going bust, or radically changing the pricing structure? Nothing.

With QR codes, you have an open standard where the destination is controlled by you! There's no relying on the largesse of multinationals to keep a service running.

In particular, I like the way The Pirate Bay (and others) have used QR codes to facilitate easy payments and donations. The QR codes contain only three variables - the payment method (BitCoin), the destination, and a message. As this is a donation there is no value set. There is a full specification for a BitCoin URI scheme which I think is fairly well designed.

I envisage a day when, on asking for the bill at a restaurant, I am presented with a paper slip totting up my purchases with a neat QR code printed at the bottom. Scanning the code will pull up my banking or credit card app and allow me to make a payment. A verifiable receipt is either shown on screen or sent directly to the restaurant.

For example:

PAY:
 WHO:Pizza Palace
 IBAN:GB29NWBK60161331926819
 CUR:EUR
 VAL:27.35
 REF:123456qwerty
 TIME:1370886496

That's enough human readable information - and machine data - to ensure the correct payment gets from one person to another. I'm sure there are some other fields which may be advantageous to add; tax rate, specific location, etc. But it certainly all fit within a QR code.

QR codes can easily be printed out using the current infrastructure of mobile POS terminals. Those terminals already have mobile network access so can be alerted in real-time when the payment is made. IBAN means we have an easy(ish) way to uniquely identify payment destinations. And, in the UK at least, we have a fairly rapid payments infrastructure.

What's needed is a simple standard and mobile banking and credit card apps to support it.

Simple...

I've been tracking the rise of QR codes in advertising for several years now. People keep asking me when NFC will take over for "boring" QR codes - based on the few live NFC examples I've seen in the UK, NFC will be trailing QR for several more years.

Let me talk you through TAP4offers' latest "effort".

The poster is fairly clear about what to expect - although I initially thought that I'd have to stretch to the top of the carriage to scan the NFC tag!

Thankfully, that's not the case. Beside every exit were these combined NFC / QR / SMS stickers. The NFC tag and QR code each had a unique tracking URL, so the owner of the service (Gunars Vucens) can see which method is being used the most. Judging from the URL and the printed information, I would guess each train carriage has a unique code.

Once the code is scanned - this happens.

What - as the kids say - The Fuck? I've no idea how much it costs to do a deal with South West Trains - but someone has wasted their money!

This is the same mistake that Clear Channel made on their QR/NFC posters.

Why bother with this? Seriously? What's the point of installing all these codes? They've been there for months - disappointing everyone who interacts with them.

Despite the advertiser's promise of a relaunch, nothing seems to be happening with these codes.

Gunars

@gunnars_v

New and upcoming #TAP4offers is due to change and expand rapidly in following weeks, keep and eye out! #nfc #tap4 #offers

---

Logo Problems

As well as the general uselessness of the destination, there is another flaw with the service.

Firstly, there's yet another NFC logo! Proxima's report to the GSMA already identified half a dozen common logos. GSMA NFC Logo, NFC Forum's N-Mark, ClearChannel's NFC Mark, etc. etc.

So, overall, a pretty pathetic effort.

If NFC is to overcome its significant obstacles - price, hardware requirements, lack of public awareness - the campaigns underpinning it must be better than this.

Spotted all over London are these bus stops with built in advertising poster. Look on the right hand side, and you'll see the interactive element.

It's pretty well designed, although the disclaimer "standard network rates apply" seems a little redundant - and weirdly placed. The QR code is oddly rotated, but that's just my personal preference.

The QR code is large enough to scan easily in broad daylight. If the code was integrated with the poster, it would also been backlit which would have been helpful when it is dark. The NFC scanned easily - once I'd flipped my phone's settings on.

Using a call to action of "Tap" and "Scan" assumes that the users will know what to do - and how to get an app if they need it.

The QR and the NFC both go to unique URLs - helpful for Clear Channel to see from where the hits are coming.

But what happens when you scan the hybrid QR/NFC?

This abomination....

What The Juddering Fuck? Why on Earth would you deploy dozens of these interactive adverts and then not point them anywhere useful? Even if the campaigns aren't ready, couldn't Clear Channel point to their YouTube Channel, or their Twitter feed, or anything!

Some people are going to interact with this poster and come to the conclusion that there's nothing worthwhile to be gained by attempting to scan again.

Clear Channel are really shooting themselves in the foot by deploying this before their technology is ready.

But! My my! What's that in the lower left corner? A QR code!

Unsurprisingly, scanning the code takes you directly to the planning application on the web. Although the site isn't specifically designed for mobile, it's light weight enough to access even on a low powered phone. The planning application lets you view and make comments, read the planning application and any associated documents, and track its progress. All rather nifty!

This is close to a perfect use-case for local government use of QR technology.

• QR codes are free (libre and gratis) meaning there's no extra expense for tax payers.
• Increases engagement with the community.
• Reduces friction between citizens and state.
• There's a great call to action (although I got confused when it said "view the application" and thought it might try to install something on my phone!)

So, well done Lambeth for trying something innovative.

Most of the QR codes that I see now are pretty good. They have clear explanatory text, point to mobile websites, and generally follow the Ten Commandments for QR codes.

But, every so often I spot one which really shouldn't have been let out in the wild. A property company (who shall remain nameless to spare their blushes) printed this QR code at the bottom of an advert - beside the logos showing how green and ISO compliant they are.

Wow! It's not that I have monster-sized fingers - that QR code really is tiny.

Let's zoom in and take a look at what the newspaper printing process has done to the code.

As we can see, the printing resolution just isn't sufficient for a code as tiny as this. The fragile pixels become an inconsistent mess, straight lines go wobbly, and the ink bleeds into the whitespace.

QR codes need unambiguous pixels with a clear delineation between content and space. Lines need to be straight, squares need to be square, and the contrast between colours needs to be high. This QR code fails on all levels.

Even if this code had been laser printed onto premium white paper, it would still be too small for many cameras to scan. It would require a macro focus that is lacking in all but high end devices.

One of the most important rules of QR codes is simply "test". This code just doesn't work. It could lead to the greatest mobile experience known to humanity - but if a user can't actually get to it, all is for naught.

I'm a long term fan of QR codes. I know some people don't like the idea of augmenting reality with specific tags for computer vision - but I do. Some people prefer RFID/NFC. Others still prefer dedicated augmented video apps.

As I've written many times before, QR codes have several substantial advantages over alternate technologies.

• QR is a free and open standard.
• Compatible with every phone with a camera.
• No need to build or use a dedicated app.
• Free to generate.

Today, in the canteen, I think I have found the quintessential example of just how radical the open simplicity of QR codes is.

Tiny sachets of salt an pepper. Created in their millions. Given away for free the world over. Each stamped with a unique ID which can be recognised easily by a computer.

For scale, this is how small they are.

Now, I'll be the first to admit that a website about salt is not the most riveting thing in the world. But that's exactly the point! The costs associated with setting this up are close to zero. Amortized over every sachet it's probably less than the cost of a grain of salt.

There's no opportunity cost lost - what else could you stick on the side of a packet that small?

I like the fact that I can instantly see nutritional information and can certainly see it being more useful on larger items. But, again, that's the point. QR codes are free - so you might as well stick them on everything.

It's this dual freedom - free to generate and free to print - which makes QR codes ubiquitous.

The main problem with NFC (aside from lack of readers, inability for a user to tell a tag is present, proximity needed, etc) is cost. Even bought in bulk, those little RFID chips have a price. Buying 20,000 of them to stick on salt packets is an extravagance an unlikely to see any ROI to offset the cost of buying the chips and changing the manufacturing process to incorporate them. Not to mention that the chips can't be recycled easily.

QR Codes? Black ink. If you're already printing onto a surface, QR codes don't require any retooling or any equipment purchases.

I know that in our modern world we often strive for technical excellence, innovation, and quality. However, where there are two relatively compatible technologies, it is usually the cheaper technology which wins.

In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitchhiker's Guide has already supplanted the great Encyclopaedia Galactica as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older, more pedestrian work in two important respects. First, it is slightly cheaper; and second, it has the words "DON'T PANIC" inscribed in large friendly letters on its cover. —Hitchhiker's Guide to the Galaxy

The Internet of Things will be powered - in part - by QR codes. Try not to get too upset about it.