What is in the SafeWA QR Codes?

Earlier this month, the Western Australian government introduced the SafeWA contact tracing app, which relies on users scanning a QR code at a venue or event in order to be added to the online register. The app doesn’t request location permission, so it is solely linking your SafeWA user account with the information in the QR code.

The QR codes were quite large, so I was kind of curious what data was held inside them. So I tried scanning one with a different barcode scanning app, which showed a standard URL-style QR code. Here is what was in a code displayed outside the Coles supermarket in Claremont:


There’s two query parameters in the URL holding what looks like hexadecimal encoded data — scanLocation and venue. The location identifier shares the prefix 5fdc5db5b27c76 with the venue ID: I’m not sure if that means the identifiers are encoding some common data, or whether they were generated using a UUID-style algorithm that generates IDs with a common authority prefix.

Before the query parameters, we have a large chunk of encoded data. Interestingly, it consists of three dot separated chunks with the first two starting with “ey”. That’s a strong indication that we’re looking at a JSON Web Token. Here, the header is:


And the payload is:


The last blob is an HMAC-SHA256 signature of the first two parts. So we’ve essentially got a signed duplicate of the query string parameters together with what looks like issue and expiry time stamps. Assuming these are standard UNIX time stamps, the token was issued at 3:43pm on 18th December. The expiry date has been set 7300 days after the issue date, which would be 20 years if every year was 365 days long.

As they’re using an HMAC signature, presumably the SafeWA app has no way to verify the token: if it did, then anyone with a copy of the app could extract the key and generate their own signed JWT blobs. If the JWT is sent back to the server verbatim, I wonder how much trouble it would be to just check that the (venue, scanLocation) pair is valid?

So there are a few ways they could simplify the QR codes:

  1. If the JWT signatures are actually necessary, dropping the query parameters would remove 20% of the data in the code.
  2. If the signature is unnecessary, dropping the JWT would remove 68% of the data in the code.
  3. Having the QR code take the form of a URL would be useful if the app was set up to claim that URL prefix, since it would allow you to start the check-in process through any barcode scanning app. They haven’t done that though, so the URL prefix could be removed for a shorter plain text QR code.

Lastly, visiting the URL from the QR code directly in the a web browser currently just redirects you to the SafeWA home page and tells you to install the app. It seems like a missed opportunity not to let people sign their attendance at that URL directly, in case they don’t have the app installed or if it is malfunctioning. It could open the door for people spoofing the Health Dept website, but it’s not clear that’s worse than the the status quo where some venues still seem to be running their own contact registers.

Update: I played around with generating QR codes generated from modified versions of the URL to see what the app would accept. The app would accept a QR code with the query parameters stripped out, and fails if the JWT is stripped from the URL. So it is definitely using the JWT token to determine the parameters. It also seems to accept tokens with the signature stripped off, so it seems possible that it doesn’t actually care about validity.

Converting BigBlueButton recordings to self-contained videos

When the pandemic lock downs started, my local Linux User Group started looking at video conferencing tools we could use to continue presenting talks and other events to members. We ended up adopting BigBlueButton: as well as being Open Source, it’s focus on education made it well suited for presenting talks. It has the concept of a presenter role, and built in support for slides (it sends them to viewers as images, rather than another video stream). It can also record sessions for later viewing.

To view those recordings though, you need to use BBB’s web player. I wanted to make sure we could keep the recordings available should the BBB instance we were using went away. Ideally, we’d just be able to convert the recordings to self contained videos files that could be archived and published along side our other recordings. There are a few tools intended to help with this:

  • bbb-recorder: screen captures Chrome displaying BBB’s web player to produce a video.
  • bbb-download: this one is intended to run on the BBB server, and combines slides, screen share and presentation audio using ffmpeg. Does not include webcam footage.

I really wanted something that would include both the camera footage and slides in one video, so decided to make my own. The result is bbb-render:


At the present, it consists of two scripts. The first is download.py, which takes the URL of a public BBB recording and downloads all of its assets to a local folder. The second is make-xges.py, which assembles those assets so they’re ready to render.

The resources retrieved by the download script include:

Video from the presenters’ cameras, plus the audio track for the presentation.
Video for screen sharing segments of the presentation. This is the same length as the webcams video, with blank footage when nothing is being shared.
Timing information for when to show the screen share video, along with the aspect ration for a particular share session
An SVG file with custom timing attributes that is uses to present the slides and whiteboard scribbles. By following links in the SVG, we can download all the slide images.
Mouse cursor position over time. This is used for the “red dot laser pointer” effect.
Not actually slides. For some reason, this is the text chat replay.

My first thought to combine the various parts was to construct a GStreamer pipeline that would play everything back together, using timers to bring slides in and out. This turned out to be easier said than done, so I started looking for something higher level.

It turns out GStreamer has that covered in the form of GStreamer Editing Services: a library intended to help write non-linear editing applications. That fits the problem really well: I’ve got a collection of assets and metadata, so just need to convert all the timing information into an appropriate edit list. I can put the webcam footage in the bottom right corner, ask for a particular slide image to display at a particular point on the timeline and go away at another point, display screen share footage, etc. It also made it easy to add a backdrop image to fill in the blank space around the slides and camera and add a bit of branding to the result.

On top of that, I can serialise that edit list to a file, rather than encoding the video directly. The ges-launch-1.0 utility can load the project to quickly play back the result without without having to wait for the video to encode.

I can even load the project in Pitivi, a video editor built on top of GES:

screenshot of Pitivi video editor

This makes it very easy to scrub through the timeline to quickly verify that everything looks correct.

At this point, the scripts can produce a crisp 1080p video that should be good enough for most presentations. There are a few areas that could be improved though:

  • If there are multiple presenters with their webcam on, we still get a single webcam video with each presenter feed shown in a square grid. It would probably look better to try and stack each presenter vertically. This could probably be done by applying videocrop as an effect to extract each individual presenter, and include the video multiple times in the project.
  • The data in cursor.xml is ignored. It would be pretty easy to display a small red circle image at the correct times and positions.
  • Whiteboard scribbles are also ignored. This would be a bit trickier to implement. It would probably involve dissecting shapes.svg into a sequence of SVGs containing the elements visible at each point in time. Making matters more complicated, the JavaScript web player adjusts the viewBox when switching to/from slides and screen share, and that changes how the coordinates of the scribbles are interpreted.

As GUADEC is using BigBlueButton this year, hopefully it should help with processing the recordings into individual videos.