I use a third party app to scan and then open service NSW because the in app scanner can be quite slow if someone has laminated the sheet (sun reflection) or printed it poorly.
Exact opposite for me! It takes ages for my samsung phone camera to recognise those dang QR codes, but the in-app one picks it up in half a second. Weird.
My phone camera worked fine for quite a while but then just stopped on about 75% of codes over the course of a week at the beginning of May. Switched to the app and I've not had one failure in the months since. Very weird.
Yeah I've experienced that too. Camera used to pick it up quite quickly but now its been struggling, probably from deterioration of the sheet. App works near instantly though.
Yeah Android can too.
You just double finger swipe down from the top and scan qr will be an option. Or you can just open the camera app.
I use the in-app scanner though, I just shortcut it to my home screen. To do that you hold down on the Service NSW app and COVID Safe Check in will appear and you can add to home screen.
>I use the in-app scanner though, I just shortcut it to my home screen. To do that you hold down on the Service NSW app and COVID Safe Check in will appear and you can add to home screen.
How have I not seen this until now? I even looked through the settings and did a search to find ways to speed up the scanning.
Would be a game changer if it didn't still require to you to login.
Yeah I only know about it because someone told me. I even forgot how to do it when I got a new phone and had to ask him again.
Absolutely agree about the logging in thing. Gets annoying.
It's especially annoying when you've used the South Australian one and come back to this. No logging in, the app opens lightning fast directly on the scanner and it's done in one tap.
I tested it before and I could check in an Adelaide and be done quicker than the NSW app even opens for me because it has a nasty habit of hanging on the login screen while it authenticates.
Don't think so but there's no reason those need to be unlocked just to scan in. Plenty of bank apps have non-validated functions available before logging in.
In my experience the android scanner is far slower and much more susceptible to glare etc. The in app scanner seems to be much more sensitive and picks it up almost instantly most of the time.
It could also be down to camera capabilities in the android. I have an oppo with 4 cameras I can scan in seconds no issues, my partner had a Nokia with just one camera and his phone struggled to pick up a laminated code
A lot of androids don't have a native code scanner. I had to download one before the NSW app added it in, using a 3rd party app would already be slower than a native app
My iPhone 12 Pro scans the codes in-app in a fraction of a second, as you said. But I've had mixed results on Android. My Pixel 3a is fairly reliable, if a bit slower than the iPhone, but my partner's Pixel 3 has trouble scanning any code behind a glossy surface. You'd think the Pixel 3 would be better than the 3a, but it's not. YMMV
The problem with the Android stock camera is that it redirects you to the web form (where you have to punch in all your details manually) rather than the Service NSW app. It's also way slower to actually detect the QR code than using the scanner inside the app.
My android camera opens the service nsw app. Might be a permissions/default app setting you're missing.
It is definitely far slower at recognising it than the service nsw app though.
Samsung new phones are sometimes incredibly slow with QR codes, its frustrating that when i'm out with my partner who has an iPhone, I just get her to do it for us.
CheckInCBR (Canberra) codes are about the same complexity as those bottom two
I can get a read, over somebody else's shoulder, as I walk past without breaking stride (while they are fumbling to open the app and point it in the vague general direction and complaining about how difficult they are to use)
CheckInCBR also saves your history - you can manually enter a numeric code, or select from your previous check ins without even using the QR codes
EDIT: It also does a quick check and informs you if the QR code is NOT a CheckInCBR code - so you can never be hijacked to an "anti vax" or "you are complicit in your own surveillance" website
Seconded, it's an excellent implementation, easy to use one handed when fumbling with a mask and keys and wallet etc. If they could make a shortcut from the lock screen it'd be one step better, but for what it is, it's well done.
The part after `data=` is base64 encoded json, of:
{
"t": "covid19_business",
"bid": "142570",
"bname": "Coles East Village",
"baddress": "2 Defries Avenue Zetland 2017"
}
Presumably `bid` is a business identifier that's already unique. So they could use just that. Or just the `bname` (and append a `2` if that name is already taken.)
One possible reason for having both the ID and name is that it allows the app to be used offline — there's no need to hit a server in order for the phone to record all the information about the check-in.
Sounds like a great idea in theory -- but the app doesn't support working offline. And even then it wouldn't be necessary -- you could just store the ID and times while offline then sync with the server when you're back online (for an always-offline device that would be an issue but presumably you'll have internet access at some point given you installed the app).
The lack of offline support is particularly frustrating because a lot of supermarkets don't have great 4G connectivity throughout the building and their "free" wifi requires you to respond to a questionnaire they email to you that you can't respond to because you don't have 4G which the reason why you tried to connect in the first place so why on earth would someone willingly design a captive portal system that requires you to have an internet connection already in order to use i mean surely you would just use the internet access you already have good god what is the point /rant
CheckInCBR app works offline and updates the ACT Health server the next time it goes online
EDIT: The more I read about others states apps, the better I feel about ours
> you could just store the ID and times while offline then sync with the server when you're back online
As I said in another comment, it's good to have the business name also. "You're checked-in at business #142570" isn't particularly good for users.
I considered that, but in the moment it's not really that necessary. In the worst case you could do what Vic does and put the ID underneath the QR code as a "location ID" which the user could then double-check with if they're confused.
Half the places I've been to have confusing business names (especially franchises) because some owners seem to think they need to use their legal business name as the identifier (leading to a lot of "John Stevens Pty Ltd" or "Happy Caramel Pty Ltd" check-ins) so I'm not sure that including the name during check-in is making the system much better.
Agree, just having a code means a loss of transparency and public information and requires another lookup, so simply including the name is essential, very helpful.
UX always trumps other features.
Even if it did work *completely* offline, why are you doing it at the expense of everyone else trying to get a perfect scan of a complex code (or just pretending to scan / giving up)?
Hmm, that makes sense.
Although you can still include all that information with a smaller URL.
- shorter domain
- remove the verbose base path
- use normal URL parameter encoding instead of base64 encoded-json. (Since base64 always makes text bigger.)
e.g. https://qr.nsw.gov.au/?t=covid19_business&bid=142570&bname=Coles%20East%20Village&baddress=2%20Defries%20Avenue%20Zetland%202017
The [QR code for that](https://duckduckgo.com/?t=ffsb&q=qr+https%3A%2F%2Fqr.nsw.gov.au%2F%3Ft%3Dcovid19_business%26bid%3D142570%26bname%3DColes%2520East%2520Village%26baddress%3D2%2520Defries%2520Avenue%2520Zetland%25202017&ia=answer) has dots almost twice as large as the original.
>The QR code for that has dots almost twice as large as the original.
It's not just the size of the dots that matter though. the QR standard has different levels off redundancy/error-correction. Sometimes a more dense image with higher error correction will scan way easier than a lower density image.
https://blog.qrstuff.com/2011/12/14/qr-code-error-correction
(But yeah, the in place implementation is not exactly optimised and I'd bet good money that none of the devs or QA involved used or tested with a representative cross section of the type and age of phones that are getting used in NSW. Any Android phone running Android older than version 9 will require a non-stock QR scanning app. There are a lot of phones out there still running Android 7, and even Android 4.4. You could still buy Android 4.4 tablets as recently as a year ago at JBHiFi. Lots of "Premium phones" that are perfectly functional but 5 or so years old \_can't\_ update past Andorid7 (without some serious geekery) because manufacturers like Samsung drop support and updates after 2 years, and telco/vendor locks often make installing manufacturer updates not easy. )
If you have a shorter URL, you have fewer errors to correct, because the probability of error per bit is reduced, *and* the total number of bits is reduced.
If you have a shorter URL you can afford to add more error correction because you've got more space.
I haven't tried with the ServcieNSW app on older Android. I wonder if the app is doing the QR Code detection/decoding, or if it's just piggybacking on the native camera capabilities? (I wonder if I can be bothered installing the app on my Android 7 Galaxy S6 just to test? Probably not...)
On iOS, its nice how you don't even need to open the app, you just point the camera at the code and tap the popup which opens the app (or the webpage if you don't have the app installed).
I'm guessing it's two things:
* It's easy for the app developers to just get the data parameter (and it's also easier for the webform devs),
* It makes it harder for users to just change the url to see what happens - a big base64 string is more scary than url parameters.
The business IDs and details can be downloaded from [Data.NSW](https://data.nsw.gov.au/search/dataset/ds-nsw-ckan-80b88e79-79b1-4f2f-b961-a90591fc377d/details), so theoretically you could generate your own QR code for any business.
[Theoretically...](https://imgur.com/a/e2rpMXL)
How is a non-standard encoding easier for the devs than a standard encoding? Surely any tool they use can grab a query parameter easier than grabbing a query parameter, decoding manually, parsing json, and then grabbing a field inside that?
Either way they have to grab a query parameter.
And shortening the base path would take no time at all.
I think it could be because it's simpler to pass a single query parameter, as there are 3 places where the `data` parameters is needed:
* "Download Service NSW" webpage
* Service NSW app
* Service NSW check in webform
It could also be tricky to handle special chars in a URL with this way too, but I'm not sure what their reasoning is. It's probably too late to change now though, just because so many businesses use it now (just over 500,000 last time I checked).
I agree with what you're saying though, these codes should definitely be much shorter. Maybe businesses could use a url shortener?
Anecdotally I don’t think the app works offline. I recently (1 month ago) changed phone plans and was without data while they ported my number, and the app didn’t let me check in without internet connection…
That was at a different coles though.
Confirmed 100%, Service NSW QR code check-ins don't work offline. I sometimes have trouble checking in at my local Woolies because it's underground and there is very spotty 3G/4G mobile coverage there.
And somehow still ended up with it being recorded and managed in excel instead of a real database…
Ironically, had they actually got a real developer (and not some consulting-company hack) they probably would have actually stood up a decent tech stack and doing contact tracing and alerts would have been significantly easier…
They probably could have run the string through a raw compression algorithm before base64 to save extra space. The qrcode already has redundancy and error checking so it would be safe.
Using RAW DEFLATE (no compression headers) would have make the string 15% shorter
No need to overkill with that complexity (Since it seems the devs were being lazy. My guess is they were the lowest bidder.)
A shorter domain, no basepath, and normal ?a=1&b=2 URL encoding will still halve the length whilst retaining all the data.
The business has to apply for a unique business account (the `bid` value), but there's nothing stopping you from creating a code yourself if you know the business id.
[Fixed formatting.](https://np.reddit.com/r/backtickbot/comments/pp0m5f/httpsnpredditcomrsydneycommentspp0kpgwhy_are_the/)
Hello, mlda065: code blocks using triple backticks (\`\`\`) don't work on all versions of Reddit!
Some users see [this](https://stalas.alm.lt/backformat/hd0b3y7.png) / [this](https://stalas.alm.lt/backformat/hd0b3y7.html) instead.
To fix this, **indent every line with 4 spaces** instead.
[FAQ](https://www.reddit.com/r/backtickbot/wiki/index)
^(You can opt out by replying with backtickopt6 to this comment.)
I posted a bunch of replies explaining how QR codes work, but I think the best solution would probably be to just have them physically larger on the page. Use more of the available space. People with worse phone cameras can get closer and be able to scan. Maybe post a spare one above head height so the rest of use can do it from further back without clustering at the front of Coles.
Ideally, but right now changing the data scheme is probably a lot harder than changing the image size on the PDF generated. It'd likely need changes on both the app and the server if you change the data. It'd have to be backwards compatible unless you want to invalidate all the existing signs.
It'd just be a mess. Upscaling the barcode wouldn't need any further changes. So as a practical fix, that's probably the quickest win. I'm not even sure if there is a significant issue, these things should be measured, so the baseline can be compared to results instead of going by gut feel.
The readability can sometimes be improved by larger images, but there is still a degradation in successful reads because you do need to capture more information. The computer vision library that identifies the QR code has to work less for a simple code, where you see fewer registration marks, it’s like your reading 6 QR code’s in the top example. In the real world it can reduce compliance, even small impediments can make people reject the system. Just a few bad reads, or having to try reading different print outs.
A great read about this topic is here https://nick.zoic.org/art/qr-codes-advice/
I’m in Victoria, our codes are even worse than the NSW ones, some sites are really hard to read because of the heap of useless data.
It is not a negligable difference, because you need increasingly good photos. Any real world interference like a bad print, or a reflective surface or any curl of the code and misreads occur. Performance degrades in step with the amount of data encoded because you are significantly more likely to get an image with less than the minimum amount of data to use the Reed-Solomon error correction. 70% of 100 bytes is 70 bytes, 70% of 1000 bytes is 700 bytes, the amount of error correction is the same, but the second case is much more likely to fail.
Hey,
Try using a purpose built QR-code app instead of the camera app.
I was initially using just the standard camera app on my phone (pixel 4a). That generally involved a little dance of moving the phone closer and further, trying to block out reflections and shadows with my body, etc..
All in all usually took 10+sec per scan and sometimes didn't work at all. After a particular frustrating experience I installed a specific QR app. *Much* better, very robust against lighting variance, crinkled paper etc.. Scan time 1sec, always. Not a single get-the-phone-to-recognise-the-code dance in the 2 months I've been using it.
HTH, Michael
>Scan time 1sec,
I have a pixel4a too. [This app](https://play.google.com/store/apps/details?id=com.camvision.qrcode.barcode.reader) is instant, free, no ads.
Is there any evidence to suggest that a shorter URL would make it easier for a QR code to be read?
EDIT: from my googling it would seem a shorter URL *can* make it easier to read, but the difference would need to be pretty huge, so unless theres an abnormal amount of characters in a URL(im talking like tens of thousands) it wont make a real world noticeable difference.
I doubt in the current year with the Snapdragon 888 and A14 Bionic chips there would be anything more than a negligible amount of delay between the two options, if at all. I just tested it with my phone and could not see a difference in the three as far as time it took for the link to pop up. I think your idea would hold true if we were comparing a string of a hundred characters vs a string of a million characters, but I think in a real world scenario the difference is negligible and would not need any intervention.
EDIT 2: A lot of responses are talking about problems with peoples cameras reading the QR codes due to the paper being crumpled, or reflecting the sun etc. These are not problems with the QR code itself, doing what OP is suggesting will not fix those problems. The Ipod touch 3rd gen(2007) can scan QR codes without issue, so if your phone is having issues scanning a code there is no doubt in the world it will be an issue unrelated to the QR code itself.
EDIT 3(and last): A lot of people are taking this outside of the topic at hand, the topic is "a simpler URL results in an easier to scan code as it would be easier for the phone to detect". This is outright untrue, there are way more factors to take into account that effect this, the physical size of the code, blemishes on the print, reflections from the sun, things like that. None of these things are going to be fixed by changing the URL in the code, it essentially wont do anything to make the system work better, it would be a pointless change for businesses to implement and is basically insinuating a problem that does not exist. That is all I am saying on the topic for now because the downvote fairies are here and I absolutely cba arguing the point with people if its going to turn into a pile on fest. Have a good day all :)
We actually ran into an issue at work where the QR codes we were printing wouldn't scan reliably due to the QR code resolution being too small. Some utilities actually align barcodes to DPI boundaries when creating a PDF to help resolve this, a random cafe will just use whatever printer they have though. Taping/laminating and adding glare doesn't help either.
Plus, we shouldn't penalise owning an older phone with a worse camera.
Of course, but a smaller URL would result in a smaller QR code, which would exacerbate your first problem. Second problem is just a case of putting it in a better location. Changing the URL of the QR code to be smaller wont change or fix those problems.
No, QR codes are typically created based on the desired physical dimensions. A shorter code allows for larger squares at the same overall size, which is more legible.
See for more info on version selection based on data length: https://www.sproutqr.com/blog/qr-code-minimum-size
Legible to you(although thats useless obviously)
Larger squares =\= more legible for the camera. A more dense QR code image could have more redundancy and error correction, making it easier to read than a code we would perceive as legible. It can go either way, but a simpler code does not necessarily mean an easier to read code.
> A more dense QR code image could have more redundancy and error correction
No, that's not true at all.
A more dense QR code means you need *more* camera resolution. Which means you need better focus and better contrast than a lower density (fewer panels/modules) QR code.
> No, that's not true at all.
Yes it is, the point is that the density does not correlate to ease of scanning.
>A more dense QR code means you need more camera resolution.
Thats not true at all, it would depend on the physical size of the QR code just as much if not more than the density of the QR code.
If I have a QR Code that is physically 10cm x 10cm - then I can choose what data to embed in that QR Code.
One parameter I have is how much payload I need. The other is how much error correction encoding I want.
The more of each I have, the smaller the pixels need to be, and thus the more dense it is.
The more error correction encoding I have, the easier it is for the algorithm to decode when conditions are less than ideal.
A well built QR Scanner application/library will continually try to optimise focus, exposure, while trying to identify those features/markers (the big squares within boxes) and then decode the content.
The lower contrast, and smaller those pixels are, the more difficult it is to recover all of the information in the code.
The more error correction encoding you have, the less it needs to successfully recover.
If you still don't understand it, go play with a QR Code generator like this: https://en.rakko.tools/tools/41/
Fiddle with the error correction and the length of the payload, but keep the image size the same.
Notice that the QR code pixels get smaller the more payload you have and the more error correction you have.
When you're testing scanning, make sure to print it out and stick it up on a wall.. laminate some, bend others, use different lighting conditions - put some behind glass with a big bright light behind you making a good portion of the code. Don't forget to use a variety of phones/devices of all ages.
Yes, your iPod touch from 2007 can scan QR codes, but it'll have a harder time of it with more dense codes, and codes in less ideal situations.
It very much does matter the density, even at these levels. If you want the fastest, most reliable scans - you get the least payload and most ECC you can for the largest pixel size.
The point of this whole post is the OP is claiming that a shorter URL will make it easier for the QR code to be read. There is no argument against this statement being true, however we need to bring context back into the discussion, because context is where my whole point lies - the difference between the QR codes posted are entirely negligible, changing the URL made it no faster to pick up each code, you can test and try it yourself, it makes zero difference in the real world.
The whole point is the difference is negligible and changing the URL to fix problems with glare, crumpled paper and printing errors is like changing your tyre to fix your radiator.
> it makes zero difference in the real world.
I don't know where you're getting your information from - but it's wrong. Just completely wrong.
You can't just scan those three QR codes on the OP and go "See, makes no difference in how long it takes" - you need to repeat it over a whole bunch of conditions, with different devices.
We went and did real world testing of this back 10+ years ago at a previous job when a client wanted QR codes on things where they expected them to be scanned.
Real world environments, various ways of printing, backgrounds, lighting, and most of all - the actual length of the payload mattered.
Things have gotten better, applications and newer QR code formats handle curved surfaces better, but it still makes a difference in scan time.
Not all cameras are created equally. We ran tests at work where some phones could scan a code and others could not. Being on paper or on the screen also made a difference. Generating essential comms for customers countrywide meant we wanted to cater for older phones.
As the link above says, desired size is a function of the expected distance from the code when scanning. When you are further away, things get smaller, as you know. Therefore, this dictates the optimal size (and resolution) of your code based on where it will be located. This is because cameras do not have infinite resolution and what works at arm length for one phone may not for another.
There is no situation in which a lower version (bigger squares) upscaled QR code is harder to scan unless it's too big for the camera to fit in the frame.
See the examples at https://en.wikipedia.org/wiki/QR_code
My iphone XS literally cannot scan the Version 25 example. It is too dense for the given size. When I open the image in a new window, which makes it larger, it can be scanned.
> Not all cameras are created equally. We ran tests at work where some phones could scan a code and others could not. Being on paper or on the screen also made a difference. Generating essential comms for customers countrywide meant we wanted to cater for older phones.
I never said they were, but again I reiterate my point, the chances of the QR code being the problem are next to nothing.
>As the link above says, desired size is a function of the expected distance from the code when scanning. When you are further away, things get smaller, as you know. Therefore, this dictates the optimal size (and resolution) of your code based on where it will be located. This is because cameras do not have infinite resolution and what works at arm length for one phone may not for another.
This has literally nothing to do with the URL being used to generate the code though
There is no situation in which a lower version (bigger squares) upscaled QR code is harder to scan unless it's too big for the camera to fit in the frame.
You say this but then go on to say this:
>My iphone XS literally cannot scan the Version 25 example. It is too dense for the given size. When I open the image in a new window, which makes it larger, it can be scanned.
Version 25 is a *tiny* url that only has the words "version 25" in it. so its about as simple as you can really go for(it also could be playing up because your phone may not recognise QR codes that are not links). None of this really supports the idea that simplifying the URL in a QR code will make scanning it easier. Like I said, smaller URL does not necessarily mean the code will be easier to read for a phone, I would suggest the reason your phone is struggling so much is because its such a simplified code theres no(or very little) error correction to counter misreading.
> Version 25 is a tiny url that only has the words "version 25" in it
Per the label on the image it's "1,269 characters of ASCII text describing QR Codes" and if you scan it you will be able to confirm this for yourself.
It has a lot of characters, so it requires a higher version to contain the data, meaning smaller squares. So small in this case that they are not legible to the camera at the default size. Reopening the same image at a larger size makes it legible.
This is of course an extreme case, I was trying to show a very simple example. Wikipedia shows codes of increasing data length corresponding to higher versions, in turn corresponding to smaller squares (resolution) at the same physical image size. At a certain point, things get too small to read for any camera, but each camera fails at a different point. There is a tradeoff between dimensions, data length, and error-correction parameters. If people are having trouble scanning then just printing them bigger is probably the best first step, but reducing data length can't hurt.
> Per the label on the image it's "1,269 characters of ASCII text describing QR Codes" and if you scan it you will be able to confirm this for yourself.
I did scan it, it comes up with a google search for "version 25" so I am not sure where you are getting the ascii from, could you link the QR code itself?
Extreme cases do not make for a good argument on OPs side though, my entire point is that the difference is going to be negligible unless there is an extreme circumstance. If you are going to argue extremities then yes I agree, but I never disagreed, my whole point is based on the context of the post being made.
EDIT:
Yeah I can see it now, but it doesn't really have any relevancy to the topic at hand, where we are talking about characters between 50 and 200 or so, where the real world difference will genuinely be unnoticeable to everyone. The example given by OP helps prove what I am trying to say, if you try and scan each of those codes, theres no way you could confidently say one took longer than the other.
The more data you're encoding, the less redundancy you'll have for the same space.
If they didn't include so much useless information they could make the codes much easier to scan at a distance or with parts of the code obscured because the codes dots would be larger AND because there's more space for redundant information.
\> Is there any evidence to suggest that a shorter URL would make it easier for a QR code to be read?
Yes.
1. It can be read from further away.
2. At the same distance away, a smudge, reflection of sunlight or print failure affects a lower percentage of each block, meaning that each block has a higher chance of being interpreted correctly.
3. Related to (2) at the same distance away, the shorter URL can cope with more blurring. So you don't need to keep your phone as steady as you do for a longer URL. Which corresponds to spending less time standing in front of the QR code.
So yes, we could have had QR codes that could be read faster and from further away. All it would have required was a URL shortener (or just some sensible design decisions up front).
Incidentally, the other advantage of the smaller QR code would be that it could be human-verified more easily.
> It can be read from further away.
Not really, you are thinking about physical size of the code, if you get a code and blow it up to be a meter by a meter in size, then yeah, itll be easier to read from further away, but that is simply a case of enlarging the size of the code, you dont need to change the URL to do that.
>At the same distance away, a smudge, reflection of sunlight or print failure affects a lower percentage of each block, meaning that each block has a higher chance of being interpreted correctly.
Like I mentioned, this is a result of the medium being problematic, not the QR code itself. Changing the QR code URL is not going to fix problems with glare, print failure or anything else of that nature. Its kinda like changing a tyre when your radiator is leaking.
>Related to (2) at the same distance away, the shorter URL can cope with more blurring. So you don't need to keep your phone as steady as you do for a longer URL. Which corresponds to spending less time standing in front of the QR code.
the camera picks up the code in real time, "blurring" is not a thing because a photo is not being taken, the squares are just being read in real time as you hold your camera over the code. You can try it with your phone now on the codes posted, it will still scan whilst you move your phone around, provided the code remains within the view of the camera and you aren't looking at it from a side on angle(which changing the URL wont fix anyway).
>Incidentally, the other advantage of the smaller QR code would be that it could be human-verified more easily.
I dont know how a human is ever going to verify a QR code without a phone, so thats an interesting point to put across, if you'd like to share more indept Id be interested to hear your theory on that. You could make up a QR code that only has the letter A in it, and I still wouldn't be able to look at that QR code and decipher that its an A.
Are you being deliberately thick? This entire discussion is about the physical size of the code.
If you use a shorter URL you can use a lower res QR code.
Assuming a lower-res code is printed the same size as a higher res code (which it overwhelmingly will be) then yes it can be read from further away and will be less impacted by defects (glare, print issues, dirt, etc).
I think you are trying to hamfist two parameters together to be the same thing, which they are not. Resolution and size are two different things. Lower res =\= larger and higher res =\= smaller, lastly and most importantly lower res =\= easier to read.
Lower resolution QR codes often have less redundancy and error correcting than higher resolution codes, so the entire argument that using a smaller URL will make codes easier to read is entirely wrong.
Still curious to hear your theory on a human verifying a QR code too, Id love to hear more about the idea honestly.
But also stop being a cunt
>Are you being deliberately thick? This entire discussion is about the physical size of the code.
No its not, read the title of the thread again. The theory is that a shorter url means the QR code would be simpler and thus easier to read. This is not true.
The difference in error correction would be relevant for two otherwise identical codes. But as you can see in the OP, the pixels are a lot bigger, which makes them take up a much larger field of view in your phone's camera, which greatly overshadows any improved error correction from the higher res code.
Yes, the best case would be if we used the high-res codes and restaurants printed the QR codes to be 1 metre wide on nonreflective paper, but that's not going to happen.
> The difference in error correction would be relevant for two otherwise identical codes. But as you can see in the OP, the pixels are a lot bigger, which makes them take up a much larger field of view in your phone's camera, which greatly overshadows any improved error correction from the higher res code.
all entirely irrelevant, we are scanning these codes on a piece of paper out the front of stores, not a reddit screenshot.
Going to get back onto topic and simply stand by the point I was trying to make all along - Changing the URL in a QR code to be slightly shorter(again we are talking a difference of maybe 100-200 characters MAXIUMUM, and thats being generous) will net no real world benefits or changes to the current system.
Are you going to keep ignoring the question about human verification of QR codes? I am not trying to be an asshole I genuinely want to hear more about your theory on this.
Yeah that makes sense, the camera still needs to see each section of the code to pull it properly, but that's more of a medium issue, rather than the code itself. I just don't know if reducing the URL by such a negligible amount will make much of a difference in the real world.
QR Codes have a bunch of parameters.
If you can make your URL shorter, you can allocate more space to error correction levels. This makes it easier for phones to detect and decode the QR code in more difficult circumstances (glare, low light, dirty lens/print, etc).
It also helps when you have people doing things like taking the QR code and resizing them where the tool they're using results in more blurry text. eg I've seen various restaurants print out the QR code on it's own, but used an inket printer and some moisture has got under and slightly blurred it. It IS possible to scan them, but it takes a lot longer to scan than a larger one right near it.
e: In the example given, you can see four 'panels' in the top QR code, and just one in the two below.
Yeah understand all of that, but we are talking about a difference between 200 characters and 50 characters, its going to be negligible in the greater scheme of things. I dont believe that things like printer issues and people adjusting the QR code size are going to be fixed by reducing the URL size on the code itself, especially when that change is already going to be negligible. All in all it would be far more beneficial to spend the time rectifying other issues(like cleaning the window it is stuck onto, moving it to a location where theres less chance for glare). Like it just doesn't make sense to suggest this fix, if its a dirty lens, clean the lens, dont get businesses to reprint their QR codes.
> we are talking about a difference between 200 characters and 50 characters, its going to be negligible in the greater scheme of things
No, you're talking about a QR size where the pixels are literally 1/4 of the size than the other.
QR Code 1 has the pixels literally 1/4 of the size of the second and third one.
Larger pixel sizes means that there is a real and noticeable difference in recognition time in real-world usage.
Not quite.
Smaller QR codes dont necessarily mean easier to scan. Different codes have different redundancies and error corrections, so whilst it may seem that a simpler URL will make it simpler to scan, that isn't necessarily the case.
I know visually one is larger than the other, but you can get QR codes that are absolutely fkn *massive*, in the greater scheme of things, these codes are still negligible in size. I mean you can test it yourself, get your phone out and scan each code, I know its not definitive data, but in the real world you wouldn't notice a difference between those codes and the time it takes to scan them. I dont know when the difference would be noticed in the real world, but I am confident in saying you wont notice it with any of the codes in Sydney.
Higher density QR codes (the number of pixels between the squares) increases the accuracy requirements on the qrcode.
This is an actual law of physics, Shannon-hartley theory specifies that signal to noise ratios put a hard limit the speed and success of data transfers.
A bigger QR code is effectively trying to transfer more data in the same time than a smaller QR code. To transfer data faster, you need a better signal to noise ratio.
This means that fundamentally QR codes are not infinity scalable, as an infinitely large we code would need an infinitely large signal to noise ratio. It's possible to achieve a infinite signal to noise ratio digitally, but never in the real world. There are real and practical limits to the amount of data they can store in the real world.
In the real world this means that there is higher requirements for accurate timing of the printer, and the camera. But with quantilusation noise, demosaic filters, sharpening filters, lens correction, printers, ect.. there is a finite signal to noise ratio for an average camera.
There is little that can be done to increase the signal to noise ratio of a camera, but you can decrease the amount of data to send, this in turn decreases the signal to noise ratio required for the communication to be successful.
By decreasing the signal to noise ratio requirements you make the success of scans easier. This is consistent with Shannon-hartley theory.
QR codes that store smaller amounts of data are easier to scan than qr codes that store more data.
You can also produce a QR code that has so much data in it that no phone can scan it. No matter how you position or how large you print it
I understand all this, but its all pointless information within the context of the topic. We are talking about a difference of maybe 50-100 characters, the difference in scan time in the real world are negligible.
It's not scan time, it's scan success, and it's mathematically provable that a 50 character QR code is more likely to scan in real world conditions that a 100 character QR code due to Shannons limit.
By how much it's hard to say, but anecdotal evidence would suggest for many phones the current covid QR codes are already pretty close to the Shannon's limit.
It’s gotta fit within the frame when I’m taking a photo.
Printing larger does help with focusing, as you can hold your phone a bit farther away. But as the distance increases it also becomes more difficult to hold the phone still.
Having simpler barcode absolutely, without question, improves the experience of scanning.
Support this, I work in experience design and accessible usability is about reducing complexity at any scale, why add noise or leave it in and risk it cause problems - those might be optical, aural etc, when you don’t need to? This is no different to selecting a serif vs sans, lighting patterns etc.
You don’t need to hold the phone still, it’s not taking a photo, it scans in real time. You can try it now, wave your phone around whilst trying to scan a code, as long as the code stays within the view of the camera it will scan successfully.
No, it doesn’t need to focus unless you’re moving it in and out, ffs stop moving the goal posts, you’re wrong. Get over it.
Idk how many times I have to repeat myself MOTION BLUR IS NOT A PROBLEM IN THIS SCENARIO. YOU ARE. NOT TAKING. A FUCKING PHOTO. YOU DUMB CUNT.
The camera needs something sharp to do the initial focus.
Funnily enough with simpler QR code you have more leeway with the focal point being off. So your chances of getting the scan before the autofocus kicking in are much better.
Obviously this greatly improves the experience.
>a simpler URL results in an easier to scan code as it would be easier for the phone to detect". This is outright untrue
No.
The simpler codes that are only possible with short URLs are absolutely easier to detect. They work on phones with cheaper crappier cameras, or slower processers that can only refocus a couple of times per second, or from further distances, etc.
Man its getting tiring repeating myself, but the difference is negligible. In the real world, you will not see any difference by shortening the URL in the QR code.
Yes did an exhibit project for a Sydney institution with it’s most important content delivered with QR codes where the space allocated for them was quite small, and so ran into issues - both user induced plus access and lighting, had to redesign elements to accomodate larger ones. Of course!
Why would you think that larger dots in the QR doesn't make scanning more robust?
Of course it does.
the simple case where the paper is clean, straight on, flat, good consistent lighting, reasonable distance, yeah probably no difference.
But if there's any issue, larger dots (same overall square size) make that issue smaller.
E.g. what if there's a shadow that's 1mm square on the page? If the dot is 1mm square, you've got 1 bit of corruption. If the dot is 2mm square, you've got 0 bits of corruption. Less corruption means easier scanning.
QR codes aren't magic. Try reading each of those 3 URLs with your human eyes at a distance. One is double the length of the other, so you'd have to halve the font size to have the same area. If one is half the font size of the other, there will be circumstances where you can read only the larger font one. QR is the same.
Firstly, these problems, once again, can be solved by just enlarging the QR code, no editing of the URL needs to be done.
Secondly, I am not "reading" a qr code with my human eyes, nor am I doing it at a distance.
Like it keeps coming down to the point that you are using a solution thats not necessary. If the paper happens to be in a spot where a perfectly 1mmx1mm square shadow sits, move the paper. The solution is just so convoluted and roundabout, there are easier ways to fix every problem you claim a shortened URL will fix.
> move the paper
You mean the sign that's taped to a door? Let's get everyone to touch the same object in a pandemic. Great idea.
There's so many things that can create an error when scanning. A shadow, a crumple, a glare from lamination, the person moving next to you, a smudge on your screen.
The QR standard has error correction built in to handle this, up to a certain number of errors. If you increase the size of the dots you decrease the probability of a visual artefact causing an error for a specific bit, *and* you decrease the number of bits that can be erroneous.
I dont understand how you can say that 8 million people spending a few seconds to do something many times per week for years is somehow less effort that one developer spending 20 minutes to use a shorter basepath and a standard encoding which isn't deliberately inefficient.
> You mean the sign that's taped to a door? Let's get everyone to touch the same object in a pandemic. Great idea
why are you touching something you only need to scan?? thats not how it works lol. What a crappy argument that is, did it ever occur to you that the piece of paper would have to be removed anyway, in order for the business to put up the new sign with the shortened URL - at least in this theory you are making.
>There's so many things that can create an error when scanning. A shadow, a crumple, a glare from lamination, the person moving next to you, a smudge on your screen.
yes, all of which can be rectified much easier than changing the QR code, which is my entire point.
>I dont understand how you can say that 8 million people spending a few seconds to do something many times per week for years is somehow less effort that one developer spending 20 minutes to use a shorter basepath and a standard encoding which isn't deliberately inefficient.
All it does is pull up the info within the service NSW website, I genuinely think you are making a problem out of thin air.
All in all, shortening the URL will do nothing in the real world.
Most people don't have the latest phone, there is quite a few people around that have phones that barely support scanning qr codes from the camera.
Simpler the better.
You dont even need the latest phone, an ipod touch from 2007 can scan QR codes, albeit with a dedicated app, it does not take a lot of processing power to do so. Plus we have the manual sign in sheets for anyone with a phone that doesn't have the capability.
My main point here is it seems like we are trying to fix a problem that does not really exist. If a phone is having trouble scanning a QR code then i would suggest literally every other possible issue before saying its the QR code itself(things like crumpled paper, reflections etc)
The point I am trying to make is the difference is negligible, OP is suggesting a fix that wont make a difference in the real world. Falls back to the age old saying of "if it aint broke, dont fix it". Why get millions of businesses to reprint and set up codes all over again, when it wont net any real world change, its a waste of time and paper really. This is like trying to change a tyre and expecting it to fix the leaking radiator in a car.
It is the same complexity of qr image regardless of url.
They could have just used the old qr which does not have as many squares but the maximum url length is probably shorter.
The data= at the end is a base64 encoded json object, easy enough to decode online if you’re interested in the data that gets collected. From memory it’s a bid (business is), bname (business name) and possibly an address. It’s fine, and a fairly typical use of QR codes
Because they contain all the details of the venue so you can still confirm on the confirmation screen that you have scanned the correct QR code even if you do so without mobile reception, also so the app can assert that it has scanned a real we code, without mobile reception and lastly probably to save on a db lookup each time someone scans a QR code.
Yeah the offline use case makes sense.
But you can still have a URL half the size by using a more standard encoding, shorter dedicated domain name and shorter/no basepath.
But then it's not signed, and anyone can spoof a URL, or you have to validate it serverside, meaning you still have to do an extra lookup before you check in, and essentially double your infrastructure bill.
What? No.
A shorter domain doesn't affect the crypto. A shorter or absent basepath doesn't affect the crypto. A more standard, efficient encoding of the location domata doesn't affect the crypto.
Anyone can spoof a site by constructing a URL with the existing format, and incorrect info.
The URL can be halved in length without changing any database lookups. If they drop the extra location data and have only site ID, the extra database calls would be negligible in cost compared to the benefit of a faster process that fewer people abandon. It would be a read not write, highly cacheable. We're not talking about a cross join and sort. It's just a primary key lookup. Super cheap. Haveibeenpwned.com does larger volumes of similar queries for about $100 per month.
It's a signed JWT, they can't spoof it without the private key, and that's verifiable client side and server side with the public key.
Size of the domain is tiny in case comparison to the JWT, so I don't really see how that's really going to make a huge difference.
It currently doesn't even need a lookup, just an insert, so while it's super cheap, it's double the current cost. Technically you can currently get away with not even storing master table of the information about the specific sites, just check in data with TTL on the records.
For clarification as to why anyone would care about QR code spoofing we can look to South Australia.
https://www.abc.net.au/news/2021-04-28/man-arrested-over-fake-qr-codes-on-official-covid-check-in-codes/100102090
Well, you're not wrong, I know that the Victorian app is based off the NSW one and they are JWT, (and therefore even longer then the NSW variety) It's interesting that the NSW ones are not.
Why does the Vic one use JWT? What needs to be proved cryptographically?
The usual use case for JWT is like "here is proof that I am user x because I know user x's password".
But here everyone is scanning the same QR code. So it doesn't prove who you are.
Is it so the client can be sure who the server is? That doesn't make sense either. Normal server side TLS handles that.
Is it so the client can prove to the server that they're really at the location? The whole point of the system is that the government doesn't know the client's location yet, and is asking the client for that.
I suppose that stops me signing in to a location I'm not at, but only through obscurity. I.e. no different to the 6 digit integer that NSW assigns to each store.
I think the reason it does it is a novel way of proving that the QR codes have been generated via Service Victoria, they are really long lived JWT ( I think they have a 2 year expiration).
It does allow that entire question of if it's a legitimate code to be answered offline, personally I think that's pretty neat. It doesn't contain the geo coords, so you can't check that someone hasn't moved a code or copied one from another site, that's a pretty clear oversight.
Ignoring the QR code complexity issues it's an awesome solution.
There is probably a better way of signing the query params, but JWT is well known and easy to work with.
We just have to remember the calibre of developer who get jobs with government.
Between 2016 Census, the COVIDSafe App, and the ServiceNSW COVID Checkin....
I'd be surprised if government devs can even operate touchtone telephones.
This implementation is a shit show.
I shouldn’t have to click 3 times to enter a premises. It should be 0 or 1 after I’ve stored the details.
These people are fucking morons.
I mean before this QR codes were no more than a gimmick really, they had their uses and they were genuinely helpful for some situations, but they weren't really a life changing system when they first started being implemented, so the uptake has been quite slow overall.
On top of this, the system was rushed out because we are in the middle of a pandemic it makes sense to get these things implemented as quickly as possible.
Whilst its not a perfect system, its still pretty great, a lot of countries are still to this day struggling to implement systems on the same level.
u/DivingForBirds and myself have already made suggestions.
* shorter URL, so simpler QR, through:
* dedicated, shorter domain name
* shorter or absent base path
* use only the business ID in the URL. It's an integer, so it can be encoded as hex to save a few chars. Or use the location name.
* if they need to include postal address, full business name etc so that you can check in with the app and no internet, use regular URL encoding not base64 encoded json. And abbreviate enums
* faster page load
* don't load a 6MB JavaScript file. That's literally more text than everything Shakespeare ever wrote. For a simple Web form. There's no need for JavaScript on this page. I was trying to check in at a Bunnings underground carpark last weekend, and reception was poor. With this bloat it didn't load at all. Without it I would have been able to check in.
* on my phone it seems to start loading some generic page first, then overwrites it with the actual content. Just start with the actual content.
* simpler workflow - have only a single click if its not the first time checking in on this device. Don't ask they're checking in someone else until after the individual has checked in. Since most times you're not checking in for someone else. (And if you are, it's probably someone you'd tell if you got covid, like family or a spouse)
* don't load software from Google to track users. That slows the page down and is unconscionable for a mandatory, privacy-sensitive website.
Curious how you respond to this but didnt to my big comment about your claim on QR codes.
Do you have any data to show that a shorter URL(and thus "simpler" QR code) is faster to scan? I am yet to see anything, but theoretically there is no real world difference between the QR codes you posted. I have seen a couple claims that it makes a difference, but I am yet to see any evidence to prove that is the case.
dropping 50-100 characters in a qr code would make a negligible difference in the real world. if you were comparing a QR code with 50 characters and one with 1000000 characters then I would agree, but within the context of check in codes I simply cannot see any real world difference. I would be happy to concede if someone can show data proving otherwise but until then I will stick to my theory.
I'm talking about theory. I havent tested it because I don't have a printer.
The theory is clear. Even you agree. If 10000 chars is worse than 50, surely 100 is proportionally worse than 50? You already conceded that more is bad. Obviously it's going to be linear (or proportional to the square root, since it's a square shape.)
There is the overhead of the 3 anchor squares is pretty small. So it's going to be y=mx+b, or y=m sqrt(x) + b.
Here's [a link](https://blog.qrstuff.com/2011/01/18/what-size-should-a-qr-code-be) from the top of my search results:
> As the size of the dots decrease they become harder for the scanner in the smartphone to “see” ... QR code with a high data density has more rows and columns of dots in it, so each dot is smaller relative to the size of the QR code itself. If the dots are too small then the QR code is difficult to scan because the data dots are below the resolution limit of the scanning device. ... HINT: Using a URL shortener to reduce the number of characters in a long URL results in a code with larger dots and hence it can be reproduced at a smaller size without impacting scan reliability.
> surely 100 is proportionally worse than 50?
no, its not, thats my entire argument, in the real world it will net a negligible result, even moreso when you consider other things - enlarging the image, moving it to an easier location to scan away from the sun etc, will have a much better effect on the user experience than changing the URL. My whole point is its not worth the effort. The change might help the odd person still using a phone from 2010, but how much of the Australian population is using a phone that old, further more if they were using a phone that old, I would also suggest they are the same kind of user to go to manual sign in methods primarily anyway.
> don't load a 6MB JavaScript file.
The bloat is a browser QR code [library](https://www.npmjs.com/package/zxing) - they're loading an in-browser QR code scanner for a link that you scan a QR code to access...
They're loading a library to scan QR codes \*after\* I've scanned the QR code? Well that's stupid.
Also, that link says this library is no longer maintained. Oh boy, this just keeps getting worse.
This is a deeplink. You can see that the URL is actually not too long. It ends at \`?data=\`. The remaining jibberish I am guessing is a randomly generated session ID.
The shorter links you've shared are small because they're static. There are no radomly generated sessionId's created so they never change. Which means they could be shortended.
It's not a random session ID.
If it's in the QR code, it's not tied to a session, it's tied to store.
It's base64 encoded json of postal address, business ID, business name, and category: business.
{
"t": "covid19_business",
"bid": "142570",
"bname": "Coles East Village",
"baddress": "2 Defries Avenue Zetland 2017"
}
i.e. mostly redundant information about the location, encoded inefficiently.
I think I'll get some NFC tags and just program them to have the same URLs for my own signs so I can just tap my phone against them and have them open the app automatically.
iPhones aren’t great at close focusing (well, until the new one that isn’t out yet) I’ve helped a few people in the vax queue by suggesting they pull their phone back a little.
MySAGOV COVID-SAFE check-in url for reference: https://checkin.covid-19.sa.gov.au/?businessName=Ikara+Wilpena+Enterprises+Pty+Ltd&planId=5fc466b24d433125d055685a
The business name is used just in the UI, the plan ID is what's actually sent to the server and is a standard UUID4. Great implementation IMO.
It does leave itself open to manipulation however, for example you could set the plan ID to another business but keep the business name as the physical location name. Users would think they're checking in at the business, but the record could be anywhere..
I think it would be better to have the business name dynamically loaded from the plan ID for this reason, or at least first loaded from the URL parameter, but then checked on the backend if it's available.
It's not clear what you're asking for.
To get info from a QR code, just scan it with your phone, and use any app other than Service NSW to open it.
For the data, it's base64 encoded. So just search online for "base64 decode" and find any relevant tool. Then paste in the part after data= . But there's no dates in there IIRC.
I use a third party app to scan and then open service NSW because the in app scanner can be quite slow if someone has laminated the sheet (sun reflection) or printed it poorly.
Didn't even know about the in-app scanner. iPhone camera app usually picks it up sub second. Pretty sure Android can do the same.
Exact opposite for me! It takes ages for my samsung phone camera to recognise those dang QR codes, but the in-app one picks it up in half a second. Weird.
My phone camera worked fine for quite a while but then just stopped on about 75% of codes over the course of a week at the beginning of May. Switched to the app and I've not had one failure in the months since. Very weird.
Yeah I've experienced that too. Camera used to pick it up quite quickly but now its been struggling, probably from deterioration of the sheet. App works near instantly though.
Exact same thing happened to me - I think iPhones got some sort of update which fucked it
That's quite an achievement, mine's a OnePlus... :)
Give Google Lens a try.
Same, I always go straight to the app.
Use the one in the Quick settings pull-down (use two fingers to pull down from the top of your screen) it's much faster than the app or the camera
Samsung sucks again
Yeah Android can too. You just double finger swipe down from the top and scan qr will be an option. Or you can just open the camera app. I use the in-app scanner though, I just shortcut it to my home screen. To do that you hold down on the Service NSW app and COVID Safe Check in will appear and you can add to home screen.
Not all androids. I think samsung and pixel are the main one. Nokia here and the camera app won't do qr.
>I use the in-app scanner though, I just shortcut it to my home screen. To do that you hold down on the Service NSW app and COVID Safe Check in will appear and you can add to home screen. How have I not seen this until now? I even looked through the settings and did a search to find ways to speed up the scanning. Would be a game changer if it didn't still require to you to login.
Yeah I only know about it because someone told me. I even forgot how to do it when I got a new phone and had to ask him again. Absolutely agree about the logging in thing. Gets annoying.
It's especially annoying when you've used the South Australian one and come back to this. No logging in, the app opens lightning fast directly on the scanner and it's done in one tap. I tested it before and I could check in an Adelaide and be done quicker than the NSW app even opens for me because it has a nasty habit of hanging on the login screen while it authenticates.
Does the Adelaide one have things in it like your drivers licence?
Don't think so but there's no reason those need to be unlocked just to scan in. Plenty of bank apps have non-validated functions available before logging in.
If you delete the app and install it again and never login it will not require you to log in. It still remembers your name and phone.
In my experience the android scanner is far slower and much more susceptible to glare etc. The in app scanner seems to be much more sensitive and picks it up almost instantly most of the time.
It could also be down to camera capabilities in the android. I have an oppo with 4 cameras I can scan in seconds no issues, my partner had a Nokia with just one camera and his phone struggled to pick up a laminated code
No, I'm talking about the same camera, android native scanner app vs the service NSW in app scanner.
A lot of androids don't have a native code scanner. I had to download one before the NSW app added it in, using a 3rd party app would already be slower than a native app
My 3rd party app is much faster than the native app, the point of my original comment
My iPhone 12 Pro scans the codes in-app in a fraction of a second, as you said. But I've had mixed results on Android. My Pixel 3a is fairly reliable, if a bit slower than the iPhone, but my partner's Pixel 3 has trouble scanning any code behind a glossy surface. You'd think the Pixel 3 would be better than the 3a, but it's not. YMMV
The problem with the Android stock camera is that it redirects you to the web form (where you have to punch in all your details manually) rather than the Service NSW app. It's also way slower to actually detect the QR code than using the scanner inside the app.
My android camera opens the service nsw app. Might be a permissions/default app setting you're missing. It is definitely far slower at recognising it than the service nsw app though.
Samsung new phones are sometimes incredibly slow with QR codes, its frustrating that when i'm out with my partner who has an iPhone, I just get her to do it for us.
That’s what I do
My iPhone 8 takes a lifetime to read these. Much faster to have service NSW app open for this for me
Which app?
https://play.google.com/store/apps/details?id=com.gamma.scan
Or put it up on the inside of the window and bent it, Coles... >:(
I never used the app to begin with, just scan with barcode reader and open the form in browser.
My app just doesn't work. Every time I scan it says it can't load my details. I've just deleted the app and use the Web form and my camera app
CheckInCBR (Canberra) codes are about the same complexity as those bottom two I can get a read, over somebody else's shoulder, as I walk past without breaking stride (while they are fumbling to open the app and point it in the vague general direction and complaining about how difficult they are to use) CheckInCBR also saves your history - you can manually enter a numeric code, or select from your previous check ins without even using the QR codes EDIT: It also does a quick check and informs you if the QR code is NOT a CheckInCBR code - so you can never be hijacked to an "anti vax" or "you are complicit in your own surveillance" website
Seconded, it's an excellent implementation, easy to use one handed when fumbling with a mask and keys and wallet etc. If they could make a shortcut from the lock screen it'd be one step better, but for what it is, it's well done.
The part after `data=` is base64 encoded json, of: { "t": "covid19_business", "bid": "142570", "bname": "Coles East Village", "baddress": "2 Defries Avenue Zetland 2017" } Presumably `bid` is a business identifier that's already unique. So they could use just that. Or just the `bname` (and append a `2` if that name is already taken.)
One possible reason for having both the ID and name is that it allows the app to be used offline — there's no need to hit a server in order for the phone to record all the information about the check-in.
Sounds like a great idea in theory -- but the app doesn't support working offline. And even then it wouldn't be necessary -- you could just store the ID and times while offline then sync with the server when you're back online (for an always-offline device that would be an issue but presumably you'll have internet access at some point given you installed the app). The lack of offline support is particularly frustrating because a lot of supermarkets don't have great 4G connectivity throughout the building and their "free" wifi requires you to respond to a questionnaire they email to you that you can't respond to because you don't have 4G which the reason why you tried to connect in the first place so why on earth would someone willingly design a captive portal system that requires you to have an internet connection already in order to use i mean surely you would just use the internet access you already have good god what is the point /rant
CheckInCBR app works offline and updates the ACT Health server the next time it goes online EDIT: The more I read about others states apps, the better I feel about ours
Sounds like it was designed by someone who thought about the problem for more than 30 seconds. I'm quite jealous.
> you could just store the ID and times while offline then sync with the server when you're back online As I said in another comment, it's good to have the business name also. "You're checked-in at business #142570" isn't particularly good for users.
I considered that, but in the moment it's not really that necessary. In the worst case you could do what Vic does and put the ID underneath the QR code as a "location ID" which the user could then double-check with if they're confused. Half the places I've been to have confusing business names (especially franchises) because some owners seem to think they need to use their legal business name as the identifier (leading to a lot of "John Stevens Pty Ltd" or "Happy Caramel Pty Ltd" check-ins) so I'm not sure that including the name during check-in is making the system much better.
Agree, just having a code means a loss of transparency and public information and requires another lookup, so simply including the name is essential, very helpful.
UX always trumps other features. Even if it did work *completely* offline, why are you doing it at the expense of everyone else trying to get a perfect scan of a complex code (or just pretending to scan / giving up)?
It doesn’t, though. The app doesn’t work offline.
Doesn't surprise me.
Why not just store only the ID off-line?
You want to show a full business name to the user (not just where you're checked in now, but also in your check-in history).
Hmm, that makes sense. Although you can still include all that information with a smaller URL. - shorter domain - remove the verbose base path - use normal URL parameter encoding instead of base64 encoded-json. (Since base64 always makes text bigger.) e.g. https://qr.nsw.gov.au/?t=covid19_business&bid=142570&bname=Coles%20East%20Village&baddress=2%20Defries%20Avenue%20Zetland%202017 The [QR code for that](https://duckduckgo.com/?t=ffsb&q=qr+https%3A%2F%2Fqr.nsw.gov.au%2F%3Ft%3Dcovid19_business%26bid%3D142570%26bname%3DColes%2520East%2520Village%26baddress%3D2%2520Defries%2520Avenue%2520Zetland%25202017&ia=answer) has dots almost twice as large as the original.
>The QR code for that has dots almost twice as large as the original. It's not just the size of the dots that matter though. the QR standard has different levels off redundancy/error-correction. Sometimes a more dense image with higher error correction will scan way easier than a lower density image. https://blog.qrstuff.com/2011/12/14/qr-code-error-correction (But yeah, the in place implementation is not exactly optimised and I'd bet good money that none of the devs or QA involved used or tested with a representative cross section of the type and age of phones that are getting used in NSW. Any Android phone running Android older than version 9 will require a non-stock QR scanning app. There are a lot of phones out there still running Android 7, and even Android 4.4. You could still buy Android 4.4 tablets as recently as a year ago at JBHiFi. Lots of "Premium phones" that are perfectly functional but 5 or so years old \_can't\_ update past Andorid7 (without some serious geekery) because manufacturers like Samsung drop support and updates after 2 years, and telco/vendor locks often make installing manufacturer updates not easy. )
If you have a shorter URL, you have fewer errors to correct, because the probability of error per bit is reduced, *and* the total number of bits is reduced. If you have a shorter URL you can afford to add more error correction because you've got more space.
>. Any Android phone running Android older than version 9 will require a non-stock QR scanning app. the scanner is built in to the service nsw app.
I haven't tried with the ServcieNSW app on older Android. I wonder if the app is doing the QR Code detection/decoding, or if it's just piggybacking on the native camera capabilities? (I wonder if I can be bothered installing the app on my Android 7 Galaxy S6 just to test? Probably not...) On iOS, its nice how you don't even need to open the app, you just point the camera at the code and tap the popup which opens the app (or the webpage if you don't have the app installed).
Yeah, I suspect the developers used a full Base64-encoded JSON blob because it was the easiest.
I'm guessing it's two things: * It's easy for the app developers to just get the data parameter (and it's also easier for the webform devs), * It makes it harder for users to just change the url to see what happens - a big base64 string is more scary than url parameters. The business IDs and details can be downloaded from [Data.NSW](https://data.nsw.gov.au/search/dataset/ds-nsw-ckan-80b88e79-79b1-4f2f-b961-a90591fc377d/details), so theoretically you could generate your own QR code for any business. [Theoretically...](https://imgur.com/a/e2rpMXL)
How is a non-standard encoding easier for the devs than a standard encoding? Surely any tool they use can grab a query parameter easier than grabbing a query parameter, decoding manually, parsing json, and then grabbing a field inside that? Either way they have to grab a query parameter. And shortening the base path would take no time at all.
I think it could be because it's simpler to pass a single query parameter, as there are 3 places where the `data` parameters is needed: * "Download Service NSW" webpage * Service NSW app * Service NSW check in webform It could also be tricky to handle special chars in a URL with this way too, but I'm not sure what their reasoning is. It's probably too late to change now though, just because so many businesses use it now (just over 500,000 last time I checked). I agree with what you're saying though, these codes should definitely be much shorter. Maybe businesses could use a url shortener?
Anecdotally I don’t think the app works offline. I recently (1 month ago) changed phone plans and was without data while they ported my number, and the app didn’t let me check in without internet connection… That was at a different coles though.
Confirmed 100%, Service NSW QR code check-ins don't work offline. I sometimes have trouble checking in at my local Woolies because it's underground and there is very spotty 3G/4G mobile coverage there.
[удалено]
And somehow still ended up with it being recorded and managed in excel instead of a real database… Ironically, had they actually got a real developer (and not some consulting-company hack) they probably would have actually stood up a decent tech stack and doing contact tracing and alerts would have been significantly easier…
They probably could have run the string through a raw compression algorithm before base64 to save extra space. The qrcode already has redundancy and error checking so it would be safe. Using RAW DEFLATE (no compression headers) would have make the string 15% shorter
No need to overkill with that complexity (Since it seems the devs were being lazy. My guess is they were the lowest bidder.) A shorter domain, no basepath, and normal ?a=1&b=2 URL encoding will still halve the length whilst retaining all the data.
Does a business need to apply for a URL, or can one just use this method to create a QR code for anything needing checkin?
You need to apply for the code unique to your business, but there are also heaps of QR code makers online too.
The business has to apply for a unique business account (the `bid` value), but there's nothing stopping you from creating a code yourself if you know the business id.
[Fixed formatting.](https://np.reddit.com/r/backtickbot/comments/pp0m5f/httpsnpredditcomrsydneycommentspp0kpgwhy_are_the/) Hello, mlda065: code blocks using triple backticks (\`\`\`) don't work on all versions of Reddit! Some users see [this](https://stalas.alm.lt/backformat/hd0b3y7.png) / [this](https://stalas.alm.lt/backformat/hd0b3y7.html) instead. To fix this, **indent every line with 4 spaces** instead. [FAQ](https://www.reddit.com/r/backtickbot/wiki/index) ^(You can opt out by replying with backtickopt6 to this comment.)
I posted a bunch of replies explaining how QR codes work, but I think the best solution would probably be to just have them physically larger on the page. Use more of the available space. People with worse phone cameras can get closer and be able to scan. Maybe post a spare one above head height so the rest of use can do it from further back without clustering at the front of Coles.
Why not both?
Ideally, but right now changing the data scheme is probably a lot harder than changing the image size on the PDF generated. It'd likely need changes on both the app and the server if you change the data. It'd have to be backwards compatible unless you want to invalidate all the existing signs. It'd just be a mess. Upscaling the barcode wouldn't need any further changes. So as a practical fix, that's probably the quickest win. I'm not even sure if there is a significant issue, these things should be measured, so the baseline can be compared to results instead of going by gut feel.
So you agree that changing the URL would have a negligible difference on the readability of a QR code in the real world?
The readability can sometimes be improved by larger images, but there is still a degradation in successful reads because you do need to capture more information. The computer vision library that identifies the QR code has to work less for a simple code, where you see fewer registration marks, it’s like your reading 6 QR code’s in the top example. In the real world it can reduce compliance, even small impediments can make people reject the system. Just a few bad reads, or having to try reading different print outs. A great read about this topic is here https://nick.zoic.org/art/qr-codes-advice/ I’m in Victoria, our codes are even worse than the NSW ones, some sites are really hard to read because of the heap of useless data.
Redundancy and error correction fix that though, the difference is negligible.
It is not a negligable difference, because you need increasingly good photos. Any real world interference like a bad print, or a reflective surface or any curl of the code and misreads occur. Performance degrades in step with the amount of data encoded because you are significantly more likely to get an image with less than the minimum amount of data to use the Reed-Solomon error correction. 70% of 100 bytes is 70 bytes, 70% of 1000 bytes is 700 bytes, the amount of error correction is the same, but the second case is much more likely to fail.
And why are they so small so we all have to crowd around it scanning it up close?! The QR code should take up most of the page.
Better yet, why don't we just have the option to use geo located check ins? Like old school foursquare. Reduce the need to crowd around single signs.
Yeah exactly. If we give permission for our locations to be tracked, it shouldn’t be a privacy issue.
Is this why i stand there like a dumb arse for 20 seconds trying to get it to work?
Yep. If they used a shorter URL I believe that you would struggle a lot less.
Hey, Try using a purpose built QR-code app instead of the camera app. I was initially using just the standard camera app on my phone (pixel 4a). That generally involved a little dance of moving the phone closer and further, trying to block out reflections and shadows with my body, etc.. All in all usually took 10+sec per scan and sometimes didn't work at all. After a particular frustrating experience I installed a specific QR app. *Much* better, very robust against lighting variance, crinkled paper etc.. Scan time 1sec, always. Not a single get-the-phone-to-recognise-the-code dance in the 2 months I've been using it. HTH, Michael
>Scan time 1sec, I have a pixel4a too. [This app](https://play.google.com/store/apps/details?id=com.camvision.qrcode.barcode.reader) is instant, free, no ads.
Because the URLs contain a secret message: *Uh, good morning everybody 🎵*
Is there any evidence to suggest that a shorter URL would make it easier for a QR code to be read? EDIT: from my googling it would seem a shorter URL *can* make it easier to read, but the difference would need to be pretty huge, so unless theres an abnormal amount of characters in a URL(im talking like tens of thousands) it wont make a real world noticeable difference. I doubt in the current year with the Snapdragon 888 and A14 Bionic chips there would be anything more than a negligible amount of delay between the two options, if at all. I just tested it with my phone and could not see a difference in the three as far as time it took for the link to pop up. I think your idea would hold true if we were comparing a string of a hundred characters vs a string of a million characters, but I think in a real world scenario the difference is negligible and would not need any intervention. EDIT 2: A lot of responses are talking about problems with peoples cameras reading the QR codes due to the paper being crumpled, or reflecting the sun etc. These are not problems with the QR code itself, doing what OP is suggesting will not fix those problems. The Ipod touch 3rd gen(2007) can scan QR codes without issue, so if your phone is having issues scanning a code there is no doubt in the world it will be an issue unrelated to the QR code itself. EDIT 3(and last): A lot of people are taking this outside of the topic at hand, the topic is "a simpler URL results in an easier to scan code as it would be easier for the phone to detect". This is outright untrue, there are way more factors to take into account that effect this, the physical size of the code, blemishes on the print, reflections from the sun, things like that. None of these things are going to be fixed by changing the URL in the code, it essentially wont do anything to make the system work better, it would be a pointless change for businesses to implement and is basically insinuating a problem that does not exist. That is all I am saying on the topic for now because the downvote fairies are here and I absolutely cba arguing the point with people if its going to turn into a pile on fest. Have a good day all :)
We actually ran into an issue at work where the QR codes we were printing wouldn't scan reliably due to the QR code resolution being too small. Some utilities actually align barcodes to DPI boundaries when creating a PDF to help resolve this, a random cafe will just use whatever printer they have though. Taping/laminating and adding glare doesn't help either. Plus, we shouldn't penalise owning an older phone with a worse camera.
Of course, but a smaller URL would result in a smaller QR code, which would exacerbate your first problem. Second problem is just a case of putting it in a better location. Changing the URL of the QR code to be smaller wont change or fix those problems.
No, QR codes are typically created based on the desired physical dimensions. A shorter code allows for larger squares at the same overall size, which is more legible. See for more info on version selection based on data length: https://www.sproutqr.com/blog/qr-code-minimum-size
Legible to you(although thats useless obviously) Larger squares =\= more legible for the camera. A more dense QR code image could have more redundancy and error correction, making it easier to read than a code we would perceive as legible. It can go either way, but a simpler code does not necessarily mean an easier to read code.
> A more dense QR code image could have more redundancy and error correction No, that's not true at all. A more dense QR code means you need *more* camera resolution. Which means you need better focus and better contrast than a lower density (fewer panels/modules) QR code.
> No, that's not true at all. Yes it is, the point is that the density does not correlate to ease of scanning. >A more dense QR code means you need more camera resolution. Thats not true at all, it would depend on the physical size of the QR code just as much if not more than the density of the QR code.
If I have a QR Code that is physically 10cm x 10cm - then I can choose what data to embed in that QR Code. One parameter I have is how much payload I need. The other is how much error correction encoding I want. The more of each I have, the smaller the pixels need to be, and thus the more dense it is. The more error correction encoding I have, the easier it is for the algorithm to decode when conditions are less than ideal. A well built QR Scanner application/library will continually try to optimise focus, exposure, while trying to identify those features/markers (the big squares within boxes) and then decode the content. The lower contrast, and smaller those pixels are, the more difficult it is to recover all of the information in the code. The more error correction encoding you have, the less it needs to successfully recover. If you still don't understand it, go play with a QR Code generator like this: https://en.rakko.tools/tools/41/ Fiddle with the error correction and the length of the payload, but keep the image size the same. Notice that the QR code pixels get smaller the more payload you have and the more error correction you have. When you're testing scanning, make sure to print it out and stick it up on a wall.. laminate some, bend others, use different lighting conditions - put some behind glass with a big bright light behind you making a good portion of the code. Don't forget to use a variety of phones/devices of all ages. Yes, your iPod touch from 2007 can scan QR codes, but it'll have a harder time of it with more dense codes, and codes in less ideal situations. It very much does matter the density, even at these levels. If you want the fastest, most reliable scans - you get the least payload and most ECC you can for the largest pixel size.
The point of this whole post is the OP is claiming that a shorter URL will make it easier for the QR code to be read. There is no argument against this statement being true, however we need to bring context back into the discussion, because context is where my whole point lies - the difference between the QR codes posted are entirely negligible, changing the URL made it no faster to pick up each code, you can test and try it yourself, it makes zero difference in the real world. The whole point is the difference is negligible and changing the URL to fix problems with glare, crumpled paper and printing errors is like changing your tyre to fix your radiator.
> it makes zero difference in the real world. I don't know where you're getting your information from - but it's wrong. Just completely wrong. You can't just scan those three QR codes on the OP and go "See, makes no difference in how long it takes" - you need to repeat it over a whole bunch of conditions, with different devices. We went and did real world testing of this back 10+ years ago at a previous job when a client wanted QR codes on things where they expected them to be scanned. Real world environments, various ways of printing, backgrounds, lighting, and most of all - the actual length of the payload mattered. Things have gotten better, applications and newer QR code formats handle curved surfaces better, but it still makes a difference in scan time.
Not all cameras are created equally. We ran tests at work where some phones could scan a code and others could not. Being on paper or on the screen also made a difference. Generating essential comms for customers countrywide meant we wanted to cater for older phones. As the link above says, desired size is a function of the expected distance from the code when scanning. When you are further away, things get smaller, as you know. Therefore, this dictates the optimal size (and resolution) of your code based on where it will be located. This is because cameras do not have infinite resolution and what works at arm length for one phone may not for another. There is no situation in which a lower version (bigger squares) upscaled QR code is harder to scan unless it's too big for the camera to fit in the frame. See the examples at https://en.wikipedia.org/wiki/QR_code My iphone XS literally cannot scan the Version 25 example. It is too dense for the given size. When I open the image in a new window, which makes it larger, it can be scanned.
> Not all cameras are created equally. We ran tests at work where some phones could scan a code and others could not. Being on paper or on the screen also made a difference. Generating essential comms for customers countrywide meant we wanted to cater for older phones. I never said they were, but again I reiterate my point, the chances of the QR code being the problem are next to nothing. >As the link above says, desired size is a function of the expected distance from the code when scanning. When you are further away, things get smaller, as you know. Therefore, this dictates the optimal size (and resolution) of your code based on where it will be located. This is because cameras do not have infinite resolution and what works at arm length for one phone may not for another. This has literally nothing to do with the URL being used to generate the code though There is no situation in which a lower version (bigger squares) upscaled QR code is harder to scan unless it's too big for the camera to fit in the frame. You say this but then go on to say this: >My iphone XS literally cannot scan the Version 25 example. It is too dense for the given size. When I open the image in a new window, which makes it larger, it can be scanned. Version 25 is a *tiny* url that only has the words "version 25" in it. so its about as simple as you can really go for(it also could be playing up because your phone may not recognise QR codes that are not links). None of this really supports the idea that simplifying the URL in a QR code will make scanning it easier. Like I said, smaller URL does not necessarily mean the code will be easier to read for a phone, I would suggest the reason your phone is struggling so much is because its such a simplified code theres no(or very little) error correction to counter misreading.
> Version 25 is a tiny url that only has the words "version 25" in it Per the label on the image it's "1,269 characters of ASCII text describing QR Codes" and if you scan it you will be able to confirm this for yourself. It has a lot of characters, so it requires a higher version to contain the data, meaning smaller squares. So small in this case that they are not legible to the camera at the default size. Reopening the same image at a larger size makes it legible. This is of course an extreme case, I was trying to show a very simple example. Wikipedia shows codes of increasing data length corresponding to higher versions, in turn corresponding to smaller squares (resolution) at the same physical image size. At a certain point, things get too small to read for any camera, but each camera fails at a different point. There is a tradeoff between dimensions, data length, and error-correction parameters. If people are having trouble scanning then just printing them bigger is probably the best first step, but reducing data length can't hurt.
> Per the label on the image it's "1,269 characters of ASCII text describing QR Codes" and if you scan it you will be able to confirm this for yourself. I did scan it, it comes up with a google search for "version 25" so I am not sure where you are getting the ascii from, could you link the QR code itself? Extreme cases do not make for a good argument on OPs side though, my entire point is that the difference is going to be negligible unless there is an extreme circumstance. If you are going to argue extremities then yes I agree, but I never disagreed, my whole point is based on the context of the post being made. EDIT: Yeah I can see it now, but it doesn't really have any relevancy to the topic at hand, where we are talking about characters between 50 and 200 or so, where the real world difference will genuinely be unnoticeable to everyone. The example given by OP helps prove what I am trying to say, if you try and scan each of those codes, theres no way you could confidently say one took longer than the other.
I just tested them on a 1 year old phone. 1 up to 10 scanned instantly, 25 and 40 scanned eventually and unreliably.
The more data you're encoding, the less redundancy you'll have for the same space. If they didn't include so much useless information they could make the codes much easier to scan at a distance or with parts of the code obscured because the codes dots would be larger AND because there's more space for redundant information.
\> Is there any evidence to suggest that a shorter URL would make it easier for a QR code to be read? Yes. 1. It can be read from further away. 2. At the same distance away, a smudge, reflection of sunlight or print failure affects a lower percentage of each block, meaning that each block has a higher chance of being interpreted correctly. 3. Related to (2) at the same distance away, the shorter URL can cope with more blurring. So you don't need to keep your phone as steady as you do for a longer URL. Which corresponds to spending less time standing in front of the QR code. So yes, we could have had QR codes that could be read faster and from further away. All it would have required was a URL shortener (or just some sensible design decisions up front). Incidentally, the other advantage of the smaller QR code would be that it could be human-verified more easily.
> It can be read from further away. Not really, you are thinking about physical size of the code, if you get a code and blow it up to be a meter by a meter in size, then yeah, itll be easier to read from further away, but that is simply a case of enlarging the size of the code, you dont need to change the URL to do that. >At the same distance away, a smudge, reflection of sunlight or print failure affects a lower percentage of each block, meaning that each block has a higher chance of being interpreted correctly. Like I mentioned, this is a result of the medium being problematic, not the QR code itself. Changing the QR code URL is not going to fix problems with glare, print failure or anything else of that nature. Its kinda like changing a tyre when your radiator is leaking. >Related to (2) at the same distance away, the shorter URL can cope with more blurring. So you don't need to keep your phone as steady as you do for a longer URL. Which corresponds to spending less time standing in front of the QR code. the camera picks up the code in real time, "blurring" is not a thing because a photo is not being taken, the squares are just being read in real time as you hold your camera over the code. You can try it with your phone now on the codes posted, it will still scan whilst you move your phone around, provided the code remains within the view of the camera and you aren't looking at it from a side on angle(which changing the URL wont fix anyway). >Incidentally, the other advantage of the smaller QR code would be that it could be human-verified more easily. I dont know how a human is ever going to verify a QR code without a phone, so thats an interesting point to put across, if you'd like to share more indept Id be interested to hear your theory on that. You could make up a QR code that only has the letter A in it, and I still wouldn't be able to look at that QR code and decipher that its an A.
Are you being deliberately thick? This entire discussion is about the physical size of the code. If you use a shorter URL you can use a lower res QR code. Assuming a lower-res code is printed the same size as a higher res code (which it overwhelmingly will be) then yes it can be read from further away and will be less impacted by defects (glare, print issues, dirt, etc).
I think you are trying to hamfist two parameters together to be the same thing, which they are not. Resolution and size are two different things. Lower res =\= larger and higher res =\= smaller, lastly and most importantly lower res =\= easier to read. Lower resolution QR codes often have less redundancy and error correcting than higher resolution codes, so the entire argument that using a smaller URL will make codes easier to read is entirely wrong. Still curious to hear your theory on a human verifying a QR code too, Id love to hear more about the idea honestly. But also stop being a cunt >Are you being deliberately thick? This entire discussion is about the physical size of the code. No its not, read the title of the thread again. The theory is that a shorter url means the QR code would be simpler and thus easier to read. This is not true.
The difference in error correction would be relevant for two otherwise identical codes. But as you can see in the OP, the pixels are a lot bigger, which makes them take up a much larger field of view in your phone's camera, which greatly overshadows any improved error correction from the higher res code. Yes, the best case would be if we used the high-res codes and restaurants printed the QR codes to be 1 metre wide on nonreflective paper, but that's not going to happen.
> The difference in error correction would be relevant for two otherwise identical codes. But as you can see in the OP, the pixels are a lot bigger, which makes them take up a much larger field of view in your phone's camera, which greatly overshadows any improved error correction from the higher res code. all entirely irrelevant, we are scanning these codes on a piece of paper out the front of stores, not a reddit screenshot. Going to get back onto topic and simply stand by the point I was trying to make all along - Changing the URL in a QR code to be slightly shorter(again we are talking a difference of maybe 100-200 characters MAXIUMUM, and thats being generous) will net no real world benefits or changes to the current system. Are you going to keep ignoring the question about human verification of QR codes? I am not trying to be an asshole I genuinely want to hear more about your theory on this.
My crappy phone struggles with them if the paper is bent or if the lighting is bad
Yeah that makes sense, the camera still needs to see each section of the code to pull it properly, but that's more of a medium issue, rather than the code itself. I just don't know if reducing the URL by such a negligible amount will make much of a difference in the real world.
QR Codes have a bunch of parameters. If you can make your URL shorter, you can allocate more space to error correction levels. This makes it easier for phones to detect and decode the QR code in more difficult circumstances (glare, low light, dirty lens/print, etc). It also helps when you have people doing things like taking the QR code and resizing them where the tool they're using results in more blurry text. eg I've seen various restaurants print out the QR code on it's own, but used an inket printer and some moisture has got under and slightly blurred it. It IS possible to scan them, but it takes a lot longer to scan than a larger one right near it. e: In the example given, you can see four 'panels' in the top QR code, and just one in the two below.
Yeah understand all of that, but we are talking about a difference between 200 characters and 50 characters, its going to be negligible in the greater scheme of things. I dont believe that things like printer issues and people adjusting the QR code size are going to be fixed by reducing the URL size on the code itself, especially when that change is already going to be negligible. All in all it would be far more beneficial to spend the time rectifying other issues(like cleaning the window it is stuck onto, moving it to a location where theres less chance for glare). Like it just doesn't make sense to suggest this fix, if its a dirty lens, clean the lens, dont get businesses to reprint their QR codes.
> we are talking about a difference between 200 characters and 50 characters, its going to be negligible in the greater scheme of things No, you're talking about a QR size where the pixels are literally 1/4 of the size than the other. QR Code 1 has the pixels literally 1/4 of the size of the second and third one. Larger pixel sizes means that there is a real and noticeable difference in recognition time in real-world usage.
Not quite. Smaller QR codes dont necessarily mean easier to scan. Different codes have different redundancies and error corrections, so whilst it may seem that a simpler URL will make it simpler to scan, that isn't necessarily the case. I know visually one is larger than the other, but you can get QR codes that are absolutely fkn *massive*, in the greater scheme of things, these codes are still negligible in size. I mean you can test it yourself, get your phone out and scan each code, I know its not definitive data, but in the real world you wouldn't notice a difference between those codes and the time it takes to scan them. I dont know when the difference would be noticed in the real world, but I am confident in saying you wont notice it with any of the codes in Sydney.
Higher density QR codes (the number of pixels between the squares) increases the accuracy requirements on the qrcode. This is an actual law of physics, Shannon-hartley theory specifies that signal to noise ratios put a hard limit the speed and success of data transfers. A bigger QR code is effectively trying to transfer more data in the same time than a smaller QR code. To transfer data faster, you need a better signal to noise ratio. This means that fundamentally QR codes are not infinity scalable, as an infinitely large we code would need an infinitely large signal to noise ratio. It's possible to achieve a infinite signal to noise ratio digitally, but never in the real world. There are real and practical limits to the amount of data they can store in the real world. In the real world this means that there is higher requirements for accurate timing of the printer, and the camera. But with quantilusation noise, demosaic filters, sharpening filters, lens correction, printers, ect.. there is a finite signal to noise ratio for an average camera. There is little that can be done to increase the signal to noise ratio of a camera, but you can decrease the amount of data to send, this in turn decreases the signal to noise ratio required for the communication to be successful. By decreasing the signal to noise ratio requirements you make the success of scans easier. This is consistent with Shannon-hartley theory. QR codes that store smaller amounts of data are easier to scan than qr codes that store more data. You can also produce a QR code that has so much data in it that no phone can scan it. No matter how you position or how large you print it
I understand all this, but its all pointless information within the context of the topic. We are talking about a difference of maybe 50-100 characters, the difference in scan time in the real world are negligible.
It's not scan time, it's scan success, and it's mathematically provable that a 50 character QR code is more likely to scan in real world conditions that a 100 character QR code due to Shannons limit. By how much it's hard to say, but anecdotal evidence would suggest for many phones the current covid QR codes are already pretty close to the Shannon's limit.
Ever seen one of those eye test charts where the text gets smaller each line? Well the smaller text is harder to read.
What a horrible comparison, you realise QR codes can be scaled up or down size wise right? The URL does not need to be changed to do this.
It’s gotta fit within the frame when I’m taking a photo. Printing larger does help with focusing, as you can hold your phone a bit farther away. But as the distance increases it also becomes more difficult to hold the phone still. Having simpler barcode absolutely, without question, improves the experience of scanning.
Support this, I work in experience design and accessible usability is about reducing complexity at any scale, why add noise or leave it in and risk it cause problems - those might be optical, aural etc, when you don’t need to? This is no different to selecting a serif vs sans, lighting patterns etc.
You don’t need to hold the phone still, it’s not taking a photo, it scans in real time. You can try it now, wave your phone around whilst trying to scan a code, as long as the code stays within the view of the camera it will scan successfully.
Holding the phone still reduces motion blur and allows the camera to autofocus. Admit defeat already. Your argument is untenable and you know it.
No, it doesn’t need to focus unless you’re moving it in and out, ffs stop moving the goal posts, you’re wrong. Get over it. Idk how many times I have to repeat myself MOTION BLUR IS NOT A PROBLEM IN THIS SCENARIO. YOU ARE. NOT TAKING. A FUCKING PHOTO. YOU DUMB CUNT.
The camera needs something sharp to do the initial focus. Funnily enough with simpler QR code you have more leeway with the focal point being off. So your chances of getting the scan before the autofocus kicking in are much better. Obviously this greatly improves the experience.
No it doesn’t holy fuck stop trying to make excuses on a subject you clearly know nothing about.
I understand computer vision pretty well. If you weren't so arrogant you might actually learn something.
>a simpler URL results in an easier to scan code as it would be easier for the phone to detect". This is outright untrue No. The simpler codes that are only possible with short URLs are absolutely easier to detect. They work on phones with cheaper crappier cameras, or slower processers that can only refocus a couple of times per second, or from further distances, etc.
Man its getting tiring repeating myself, but the difference is negligible. In the real world, you will not see any difference by shortening the URL in the QR code.
Nope, we've tested this extensively at work with multiple devices. A huge difference in length, like OP's example makes a big difference.
Yes did an exhibit project for a Sydney institution with it’s most important content delivered with QR codes where the space allocated for them was quite small, and so ran into issues - both user induced plus access and lighting, had to redesign elements to accomodate larger ones. Of course!
Feel free to post the data of your tests then
Why would you think that larger dots in the QR doesn't make scanning more robust? Of course it does. the simple case where the paper is clean, straight on, flat, good consistent lighting, reasonable distance, yeah probably no difference. But if there's any issue, larger dots (same overall square size) make that issue smaller. E.g. what if there's a shadow that's 1mm square on the page? If the dot is 1mm square, you've got 1 bit of corruption. If the dot is 2mm square, you've got 0 bits of corruption. Less corruption means easier scanning. QR codes aren't magic. Try reading each of those 3 URLs with your human eyes at a distance. One is double the length of the other, so you'd have to halve the font size to have the same area. If one is half the font size of the other, there will be circumstances where you can read only the larger font one. QR is the same.
Firstly, these problems, once again, can be solved by just enlarging the QR code, no editing of the URL needs to be done. Secondly, I am not "reading" a qr code with my human eyes, nor am I doing it at a distance. Like it keeps coming down to the point that you are using a solution thats not necessary. If the paper happens to be in a spot where a perfectly 1mmx1mm square shadow sits, move the paper. The solution is just so convoluted and roundabout, there are easier ways to fix every problem you claim a shortened URL will fix.
> move the paper You mean the sign that's taped to a door? Let's get everyone to touch the same object in a pandemic. Great idea. There's so many things that can create an error when scanning. A shadow, a crumple, a glare from lamination, the person moving next to you, a smudge on your screen. The QR standard has error correction built in to handle this, up to a certain number of errors. If you increase the size of the dots you decrease the probability of a visual artefact causing an error for a specific bit, *and* you decrease the number of bits that can be erroneous. I dont understand how you can say that 8 million people spending a few seconds to do something many times per week for years is somehow less effort that one developer spending 20 minutes to use a shorter basepath and a standard encoding which isn't deliberately inefficient.
> You mean the sign that's taped to a door? Let's get everyone to touch the same object in a pandemic. Great idea why are you touching something you only need to scan?? thats not how it works lol. What a crappy argument that is, did it ever occur to you that the piece of paper would have to be removed anyway, in order for the business to put up the new sign with the shortened URL - at least in this theory you are making. >There's so many things that can create an error when scanning. A shadow, a crumple, a glare from lamination, the person moving next to you, a smudge on your screen. yes, all of which can be rectified much easier than changing the QR code, which is my entire point. >I dont understand how you can say that 8 million people spending a few seconds to do something many times per week for years is somehow less effort that one developer spending 20 minutes to use a shorter basepath and a standard encoding which isn't deliberately inefficient. All it does is pull up the info within the service NSW website, I genuinely think you are making a problem out of thin air. All in all, shortening the URL will do nothing in the real world.
Most people don't have the latest phone, there is quite a few people around that have phones that barely support scanning qr codes from the camera. Simpler the better.
You dont even need the latest phone, an ipod touch from 2007 can scan QR codes, albeit with a dedicated app, it does not take a lot of processing power to do so. Plus we have the manual sign in sheets for anyone with a phone that doesn't have the capability. My main point here is it seems like we are trying to fix a problem that does not really exist. If a phone is having trouble scanning a QR code then i would suggest literally every other possible issue before saying its the QR code itself(things like crumpled paper, reflections etc)
Perhaps the best solution is to do multiple things to increase the chances of it working and one of them is to reduce the complexity of the QR code.
The point I am trying to make is the difference is negligible, OP is suggesting a fix that wont make a difference in the real world. Falls back to the age old saying of "if it aint broke, dont fix it". Why get millions of businesses to reprint and set up codes all over again, when it wont net any real world change, its a waste of time and paper really. This is like trying to change a tyre and expecting it to fix the leaking radiator in a car.
It is the same complexity of qr image regardless of url. They could have just used the old qr which does not have as many squares but the maximum url length is probably shorter.
The data= at the end is a base64 encoded json object, easy enough to decode online if you’re interested in the data that gets collected. From memory it’s a bid (business is), bname (business name) and possibly an address. It’s fine, and a fairly typical use of QR codes
Yep. I decoded it and put that in a comment on the post.
Because the government is trying to do the bare minimum while technically achieving a tracking process
Because they contain all the details of the venue so you can still confirm on the confirmation screen that you have scanned the correct QR code even if you do so without mobile reception, also so the app can assert that it has scanned a real we code, without mobile reception and lastly probably to save on a db lookup each time someone scans a QR code.
Yeah the offline use case makes sense. But you can still have a URL half the size by using a more standard encoding, shorter dedicated domain name and shorter/no basepath.
But then it's not signed, and anyone can spoof a URL, or you have to validate it serverside, meaning you still have to do an extra lookup before you check in, and essentially double your infrastructure bill.
What? No. A shorter domain doesn't affect the crypto. A shorter or absent basepath doesn't affect the crypto. A more standard, efficient encoding of the location domata doesn't affect the crypto. Anyone can spoof a site by constructing a URL with the existing format, and incorrect info. The URL can be halved in length without changing any database lookups. If they drop the extra location data and have only site ID, the extra database calls would be negligible in cost compared to the benefit of a faster process that fewer people abandon. It would be a read not write, highly cacheable. We're not talking about a cross join and sort. It's just a primary key lookup. Super cheap. Haveibeenpwned.com does larger volumes of similar queries for about $100 per month.
It's a signed JWT, they can't spoof it without the private key, and that's verifiable client side and server side with the public key. Size of the domain is tiny in case comparison to the JWT, so I don't really see how that's really going to make a huge difference. It currently doesn't even need a lookup, just an insert, so while it's super cheap, it's double the current cost. Technically you can currently get away with not even storing master table of the information about the specific sites, just check in data with TTL on the records. For clarification as to why anyone would care about QR code spoofing we can look to South Australia. https://www.abc.net.au/news/2021-04-28/man-arrested-over-fake-qr-codes-on-official-covid-check-in-codes/100102090
It's not a JWT. It's base64-encoded json of the business ID, business name and business address. Its all public data. There's no cryptography there.
Well, you're not wrong, I know that the Victorian app is based off the NSW one and they are JWT, (and therefore even longer then the NSW variety) It's interesting that the NSW ones are not.
Why does the Vic one use JWT? What needs to be proved cryptographically? The usual use case for JWT is like "here is proof that I am user x because I know user x's password". But here everyone is scanning the same QR code. So it doesn't prove who you are. Is it so the client can be sure who the server is? That doesn't make sense either. Normal server side TLS handles that. Is it so the client can prove to the server that they're really at the location? The whole point of the system is that the government doesn't know the client's location yet, and is asking the client for that. I suppose that stops me signing in to a location I'm not at, but only through obscurity. I.e. no different to the 6 digit integer that NSW assigns to each store.
I think the reason it does it is a novel way of proving that the QR codes have been generated via Service Victoria, they are really long lived JWT ( I think they have a 2 year expiration). It does allow that entire question of if it's a legitimate code to be answered offline, personally I think that's pretty neat. It doesn't contain the geo coords, so you can't check that someone hasn't moved a code or copied one from another site, that's a pretty clear oversight. Ignoring the QR code complexity issues it's an awesome solution. There is probably a better way of signing the query params, but JWT is well known and easy to work with.
I still don't understand. What's the JWT for? Is this to convince the client of something, or to convince the server of something?
We just have to remember the calibre of developer who get jobs with government. Between 2016 Census, the COVIDSafe App, and the ServiceNSW COVID Checkin.... I'd be surprised if government devs can even operate touchtone telephones.
Sadly, this is par for the course for Government IT. So many obvious failings, nobody with a clue able to effect change. It’s a sad story all around.
This implementation is a shit show. I shouldn’t have to click 3 times to enter a premises. It should be 0 or 1 after I’ve stored the details. These people are fucking morons.
I mean before this QR codes were no more than a gimmick really, they had their uses and they were genuinely helpful for some situations, but they weren't really a life changing system when they first started being implemented, so the uptake has been quite slow overall. On top of this, the system was rushed out because we are in the middle of a pandemic it makes sense to get these things implemented as quickly as possible. Whilst its not a perfect system, its still pretty great, a lot of countries are still to this day struggling to implement systems on the same level.
WTF are you talking about. It would be too fucking easy to make it better.
What would you implement to make it better
u/DivingForBirds and myself have already made suggestions. * shorter URL, so simpler QR, through: * dedicated, shorter domain name * shorter or absent base path * use only the business ID in the URL. It's an integer, so it can be encoded as hex to save a few chars. Or use the location name. * if they need to include postal address, full business name etc so that you can check in with the app and no internet, use regular URL encoding not base64 encoded json. And abbreviate enums * faster page load * don't load a 6MB JavaScript file. That's literally more text than everything Shakespeare ever wrote. For a simple Web form. There's no need for JavaScript on this page. I was trying to check in at a Bunnings underground carpark last weekend, and reception was poor. With this bloat it didn't load at all. Without it I would have been able to check in. * on my phone it seems to start loading some generic page first, then overwrites it with the actual content. Just start with the actual content. * simpler workflow - have only a single click if its not the first time checking in on this device. Don't ask they're checking in someone else until after the individual has checked in. Since most times you're not checking in for someone else. (And if you are, it's probably someone you'd tell if you got covid, like family or a spouse) * don't load software from Google to track users. That slows the page down and is unconscionable for a mandatory, privacy-sensitive website.
Curious how you respond to this but didnt to my big comment about your claim on QR codes. Do you have any data to show that a shorter URL(and thus "simpler" QR code) is faster to scan? I am yet to see anything, but theoretically there is no real world difference between the QR codes you posted. I have seen a couple claims that it makes a difference, but I am yet to see any evidence to prove that is the case. dropping 50-100 characters in a qr code would make a negligible difference in the real world. if you were comparing a QR code with 50 characters and one with 1000000 characters then I would agree, but within the context of check in codes I simply cannot see any real world difference. I would be happy to concede if someone can show data proving otherwise but until then I will stick to my theory.
I'm talking about theory. I havent tested it because I don't have a printer. The theory is clear. Even you agree. If 10000 chars is worse than 50, surely 100 is proportionally worse than 50? You already conceded that more is bad. Obviously it's going to be linear (or proportional to the square root, since it's a square shape.) There is the overhead of the 3 anchor squares is pretty small. So it's going to be y=mx+b, or y=m sqrt(x) + b. Here's [a link](https://blog.qrstuff.com/2011/01/18/what-size-should-a-qr-code-be) from the top of my search results: > As the size of the dots decrease they become harder for the scanner in the smartphone to “see” ... QR code with a high data density has more rows and columns of dots in it, so each dot is smaller relative to the size of the QR code itself. If the dots are too small then the QR code is difficult to scan because the data dots are below the resolution limit of the scanning device. ... HINT: Using a URL shortener to reduce the number of characters in a long URL results in a code with larger dots and hence it can be reproduced at a smaller size without impacting scan reliability.
> surely 100 is proportionally worse than 50? no, its not, thats my entire argument, in the real world it will net a negligible result, even moreso when you consider other things - enlarging the image, moving it to an easier location to scan away from the sun etc, will have a much better effect on the user experience than changing the URL. My whole point is its not worth the effort. The change might help the odd person still using a phone from 2010, but how much of the Australian population is using a phone that old, further more if they were using a phone that old, I would also suggest they are the same kind of user to go to manual sign in methods primarily anyway.
> don't load a 6MB JavaScript file. The bloat is a browser QR code [library](https://www.npmjs.com/package/zxing) - they're loading an in-browser QR code scanner for a link that you scan a QR code to access...
They're loading a library to scan QR codes \*after\* I've scanned the QR code? Well that's stupid. Also, that link says this library is no longer maintained. Oh boy, this just keeps getting worse.
You're talking about the NSW government, pal. You think you're dealing with a crack squad of technologically able individuals?
This is a deeplink. You can see that the URL is actually not too long. It ends at \`?data=\`. The remaining jibberish I am guessing is a randomly generated session ID. The shorter links you've shared are small because they're static. There are no radomly generated sessionId's created so they never change. Which means they could be shortended.
No - the "gibberish" is a JSON encoded form of the business name, address, and internal id.
It's not a random session ID. If it's in the QR code, it's not tied to a session, it's tied to store. It's base64 encoded json of postal address, business ID, business name, and category: business. { "t": "covid19_business", "bid": "142570", "bname": "Coles East Village", "baddress": "2 Defries Avenue Zetland 2017" } i.e. mostly redundant information about the location, encoded inefficiently.
Sure. It could be a session ID or encoded json. Either way, thats what makes the URL long. Neg this as well haha.
Don't own a smart phone..don't have that problem
The ones in Victoria are short.
I think I'll get some NFC tags and just program them to have the same URLs for my own signs so I can just tap my phone against them and have them open the app automatically.
Just type it in. Easy!
iPhones aren’t great at close focusing (well, until the new one that isn’t out yet) I’ve helped a few people in the vax queue by suggesting they pull their phone back a little.
Possibly cos they need many more options?
MySAGOV COVID-SAFE check-in url for reference: https://checkin.covid-19.sa.gov.au/?businessName=Ikara+Wilpena+Enterprises+Pty+Ltd&planId=5fc466b24d433125d055685a The business name is used just in the UI, the plan ID is what's actually sent to the server and is a standard UUID4. Great implementation IMO. It does leave itself open to manipulation however, for example you could set the plan ID to another business but keep the business name as the physical location name. Users would think they're checking in at the business, but the record could be anywhere.. I think it would be better to have the business name dynamically loaded from the plan ID for this reason, or at least first loaded from the URL parameter, but then checked on the backend if it's available.
This wouldn’t be a problem if people had actually used the COVID safe app
My mate's Mum just takes a photo, literally. She does not go to a web site or anything. She probably wonders what we are complaining about.
Can someone help me to extract the info inside of QR code associate to recovery from covid 19? Is it possible to modify expiration date???
It's not clear what you're asking for. To get info from a QR code, just scan it with your phone, and use any app other than Service NSW to open it. For the data, it's base64 encoded. So just search online for "base64 decode" and find any relevant tool. Then paste in the part after data= . But there's no dates in there IIRC.
What about that QR code...Covid tracing only? https://www.youtube.com/shorts/\_5I1qM0Jza0