Hacker News Reader

Comment by rswail | Hacker News Reader

I've worked in public transport ticketing for the past 30 years including the first system outside Japan (Hong Kong's Octopus).

The problem with QR codes:

1. If they're printed, they can be copied.

2. "Dynamic" QR codes can be screenshot.

3. They're read-only (by definition)

4. Readers are slow, require good orientation by the user.

NFC is good because it's read/write, has a ~10cm range, the larger cards can hold up to 4K of data, the ultralights can replace single journey tickets and can be recycled like magnetics being captured at exit.

View on HN

I don't think the suggestion is the QR code contains the ticket info, but that the QR code is the unique tag into the back end virtual ticket system. 1 to 3 are not relevant in that context, and 4 isn't borne out in my experience with modern readers (they're used in the bar code mix at parkrun and they read time is vanishingly fast with a smart phone, generally better than barcodes). The number of bits might increase the difficulty if capturing the code, but I would very surprised if a fast, robust system can't be built.

The huge disadvantage of NFC in this context is the electronic waste necessarily produced.

The problem with expecting a "unique tag into the back end" is that these systems have to work offline.

The QR codes are significantly slower to read than NFC.

I've built both NFC and QR (and ye olde fashioned magnetic stripe) ticketing systems.

NFC doesn't necessarily create any additional e-waste. In Chicago we have an NFC system, and people typically just link their phone to their account and use that to pay.

I still use a physical card - so that I have a backup option in case something happens to my phone - but even there the volume of waste is trivial. I've had my current transit card for ages, and it doesn't expire until 2037. It's possible that the only technological decision I've made that generated less e-waste was deciding to splurge on a mechanical watch instead of a quartz model.

Well, yes, but the article is about a disposable nfc ticket.

Those are more for single rides by people who rarely or never use the transit system. I've had the same Carte Opus for years and just bring it with me and refill whenever I visit Montreal. And the disposable paper cards are being phased out. I'm not sure when the rollout will be, but Montreal is currently working on upgrading the system to allow people to just tap-to-pay at the turnstiles using their phones or compatible credit and debit cards.

Which is not something that you could do with a QR system. I don't know that anything is inherently wrong with QR codes, but they do seem to be a choice that's more appropriate for countries like China where the existing electronic payment infrastructure uses QR codes. In North America, by contrast, things have generally settled on NFC, and I think that that reason alone probably makes NFC the better option for North American transit systems.

> Montreal is currently working on upgrading the system to allow people to just tap-to-pay at the turnstiles using their phones or compatible credit and debit cards. > Which is not something that you could do with a QR system

I've got several apps that display QR codes on the screen for an external reader. One of them is for my health insurance id card (a simple 10 digit number), another shows my COVID vaccination status (this one is complicated, and I'm not sure why they used a QR code for it. It must include batch identification and other information given the size)

By tap-to-pay, I mean you need no special apps, you need no special accounts, any of that. You can pay with any physical credit or debit card that supports tap-to-pay, or you can use any credit or debit card you have loaded into your phone.

With a QR code like that, people still need to install an app, set up an account, etc. It's just a lot more friction. In cities where I can tap-to-pay, getting set up to ride a bus or train for the first time takes literally zero time; I'm already set up. If I need anything special - apps, accounts, system-specific QR codes, etc - then the setup time instantly goes up to a minimum of 10 minutes. It's a relatively large barrier to entry for infrequent riders, and ultimately serves to discourage use of public transit.

Really? Setting up contactless payment is quicker than having a QR code image? I use QR codes on the UK train system and I don't have any special apps. It seems to integrate with Google wallet too, which surprised me.

The point of the disposables is that they use the same technology (NFC/RFID) as the more robust long term multi-use NFC cards.

So if you're replacing an existing magnetic system, you can reuse the magnetic transports (belts/motors etc) for single use, including capture-at-exit and recycling for single journeys, while also adopting the NFC for multiple use.

On rail systems with gates, these disposable "ultralite" RFID tickets are usually put through the old slot that used to take magentic tickets.

Exit gates usually capture the ticket on exit when it has been used up (ie single journeys, or after the number of trips encoded on the ticket).

These can (and are) recycled numerous times.

> and 4 isn't borne out in my experience

To bolster your point, aren't there whole countries where stores and street sales float on top of QR codes?

Yes- of interest:

China's Big Tech companies taught Asia to pay by scanning QR codes, but made a mess along the way

https://www.theregister.com/2024/06/17/asia_qr_code_obsessio...

In China, QR Codes are used for public transport too, and I found them just as fast as NFC readers (and faster than the slow readers used by the NS in The Netherlands)

Until you go to another city and discover that the local bus company has decided that instead of just letting you pay by Wechat pay or Alipay, you need to install their proprietary app to generate the QR code for the bus to scan, at which point the app then just turns it into a Wechat pay or Alipay transaction at the end. No benefit to the user, it just allows the bus company to extract all your PII in the process. Actually, they're not all proprietary apps, but there are several from competing companies, and you have to use whichever one the city has chosen.

Actually, I think part of the reason is that so they know who's on the bus in case it's involved in an accident, because if you buy a ticket from a bus station for a "short distance" (so out of the city, but within about 40km), you also have to provide them with a phone number even though they never call you or send you an SMS using that number.

>Actually, I think part of the reason is that so they know who's on the bus in case it's involved in an accident

The CCP certainly do want to know who's on the bus, but not for the reasons you stated.

The time to process a payment at a retail outlet is ~1s+, the time required for public transport is usually <0.5s including mechanical release of barriers etc.

QRs are dramatically slower than NFC.

Those QR codes are validated online.

Transit has to work offline.

An always-online requirement is not feasible everywhere.

You can fail open. The QR code contained a signed ticket ID and expiry. You locally validate the signature and expiry and remotely attempt to validate reuse. If the remote validation is slow or fails just accept the ticket and log it.

That is what happens, however it exposes the transit company to a risk that many of them aren't willing to accept.

1. Thats ok. If you’re expecting your rfid tokens not to be copied just because it seems inconvenient to do so, you’re in for a surprise! Your ticketing system cannot assume tickets in any form cannot be replicated- they can be and if you introduce such a vulnerability in your system, you will lose revenue

2. As per 1, no issue

3. That’d be a great feature if true, I’m all for immutability. However , qr codes can be defaced easily, hopefully the built in checksum defend against that. a more likely threat your system needs to defend against is that new qr codes can be generated extremely quickly

4. Both systems are the same speed, both systems require accurate targeting by the user, an rfid token slightly askew of the reader will not read since it won’t be able to influence / absorb the generated rf - most of these systems work by providing power to the rfid token and it communicates back not by transmitting its own signal but by exerting influence on the signal it’s receiving. It’s a very very low power interaction and very sensitive to positioning

A better problem than 4 is that you entail staff overheads with a visual system to keep them clean.

Read / write is a bad feature, you will lose ticket sales.

Recycling these is not practical. Direct reuse risks jamming the vending machine (used tickets end up subtly bent, very hard to reliably deal with), actual recycling isn’t viable, the energy required and emissions produced exceed that of creation of a new card from raw materials.

> Your ticketing system cannot assume tickets in any form cannot be replicated- they can be and if you introduce such a vulnerability in your system, you will lose revenue

Yes, the question is not whether such system would be abused, but how much. But this is in the end what businesses care about.

Will QR codes be abused more than NFC chips? Likely yes.

Will it produce a larger financial loss than the cost of the NFC chips?

Can I mitigate these losses by a centralized validation system (each terminal needs a network connection with low latency guarantees)? Sure, but how much will it cost?

A centralized system is how tags work already, so you can't toss your ticket to your friend behind you and have them reuse it.

These NFC chips have counters to deactivate themselves after the allocated number of trips has been reached.

40 years ago we had a read-write system based on mechanical trimming of a piece of card and a physical time stamp[1]. It's absolutely possible to roll out a system to keep track of journeys that doesn't require fancy embedded ICs.

[1] https://www.facebook.com/uktvads/videos/kerching-a-saverstri...

NFC tickets have "antipassback" features, eg, stores the last tap so you can't "toss your ticket to your friend behind you".

1. NFC tickets with embedded security are robust against replication, at least to the extent required for transit.

On 4, QRs are substantially slower to be read and decoded. NFC/RFID have a range of ~100mm and the field shape is dependent on the antenna design, however it is way more tolerant than QR using IR/laser. As for "entail staff overheads", we are talking about systems that process thousands of taps/day through single gates. Anything that reduces maintenance requirements is absolutely a priority.

As for "read/write is a bad feature", I don't really understand your point.

Ultralite RFID/NFC tickets are routinely recycled where they are used to replace old magnetic systems that have belt transports for the magnetic tickets. The read/write heads of the magnetic stripe are replaced with NFC readers but the belt transport and capture mechanisms remain.

I’ve found NDEF cards that can hold 16KB & 32KB, even as much as 64KB. That may be too much capacity for ticketing but it blows QR codes out of the water

When all you need is a unique identifier, what's the advantage?

That is the issue. If it was just a matter of a unique identifier, then a read only token would be fine.

However, for most transit, there is some form of "check in/out" (either through barriers/gates or via validation/inspection). This is combined with rules about "antipassback" (ie one user passing the token back to another to reuse), as well as "total time in system" (ie to avoid people staying in the system all day).

There are also rules that take into account entry/exit times (eg peak/off-peak), entry/exit locations (eg core/non-core zones) etc.

All of these rules require either:

a) An always online set of validators to be able to contact the backend that is maintaining the information, or,

b) a way to record the information on the token so that it is physically transported from one validation location to another.

It also is needed for inspection purposes during a trip.

None in that case. But with these cards there’s less need for centralization of data storage and code logic

>> there’s less need for centralization of data storage and code logic

You make it sound like less moving parts are a bad thing :-)

I know what you're getting at though - the decentralized tolerance of network partitions and the ability to provide higher availability and faster decision speed at the entry barrier.

The system design constraints are hard but not impossible, my back of napkin maths says 5k/ticket scans per second with 99th percentile latency < 1000ms not only satisfies every use case that exists today but allows for 3x population growth beyond!

There's a few things in your favour when designing this system though. For example, in the case of network partition, you have geographic locality so a pen drive delivered a couple of times per day is likely feasible.

The usual maximum time allowed for tap->barrier open is a maximum of 450ms. That includes all read/write times for the token, display changes, fare calculations and deductions, all business rule validation (eg hotlisting stolen tokens etc).

The system I recently put in allowed for that 450ms, the time broke down to:

1) NFC comms ~100ms

2) Network comms ~50-100ms

3) Physical relays (releasing barriers etc) 100-200ms

During peak periods the usual rate expected is 30-40 passengers through a gate/minute, which includes all of the time above, plus the passengers actually walking through the barriers (usually ~2m).

“99th percentile”

Not relevant. The maximum specified by contract is usually 450-500ms.

The barriers at rail stations have to have a defined maximum throughput of passengers, because it affects safety during emergencies etc. Most barriers are required to maintain somewhere between 30 and 45 passengers per minute.

Yes they can "default be open" and usually have emergency modes that disable validation entirely, but the speed during peak hour periods has to maintain the passenger flow.

1000ms is a surprisingly long wait at a ticket barrier, though! Latency is everything in this use case...

Usual requirement is <500ms from tap to passenger through the barrier, which includes not only the validation/fare deduction etc, but also the display and barrier unlock.

Reply on news.ycombinator.com