Earlier quoted context omitted.
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.
The tiny chip that powers Montreal subway tickets
511–520 of 525 posts
Re: The tiny chip that powers Montreal subway tickets
#512Earlier quoted context omitted.
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…
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…
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.
Re: The tiny chip that powers Montreal subway tickets
#513Earlier quoted context omitted.
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?
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.
Re: The tiny chip that powers Montreal subway tickets
#514Earlier quoted context omitted.
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…
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).
Re: The tiny chip that powers Montreal subway tickets
#515Earlier quoted context omitted.
>> 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…
1000ms is a surprisingly long wait at a ticket barrier, though! Latency is everything in this use case...
Re: The tiny chip that powers Montreal subway tickets
#516Earlier quoted context omitted.
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 on…
Well, yes, but the article is about a disposable nfc ticket.
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.
Re: The tiny chip that powers Montreal subway tickets
#517Earlier quoted context omitted.
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…
> 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?
Re: The tiny chip that powers Montreal subway tickets
#518Earlier quoted context omitted.
> 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…
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.
Re: The tiny chip that powers Montreal subway tickets
#519Re: The tiny chip that powers Montreal subway tickets
#520FTA: > It's remarkable that these NFC chips can be manufactured so cheaply that they are disposable In our times, where we slowly understand that we have problems of resources and waste, I find it very disturbing that "disposable" is considered a positive achievement by the author.
These are so tiny that throwing them away is a drop in the bucket in terms of waste. It's less waste than your morning coffee produces.