( Last edited on 11/25/2016. )
On the Island Of Montreal, bus and subway fares have been handled for many years via a contact-less smart-card, called our “Opus Card”. Most residents “recharge” their fares at designated commercial establishments, but those so inclined may instead buy a USB-connected reader for this card, which also has contacts, which the privately-used readers use to recharge them.
I am one passenger, who chooses to pay their fares this way at home, by plugging the USB-cable of the card-reader into my remaining Windows 7 computer named ‘Mithral’, and by going to a Web-site, where we can provide payment information.
Until last month, the way in which this system worked was:
- We install a device-driver for the actual card reader – which is chosen for us by the designated site.
- We kept our Java installation up-to-date.
- The site charges our payment method, validated on their side.
- The Web-site deployed and launched a Java application with each use, that connected to the card reader and wrote changes to the data on the card.
At least in theory it was possible to say, that this system was based on an open standard, that being Java.
But as of this month, the transit authority has switched to a different system. We still need the actual USB driver for the card reader. But now we must also download what they call their ‘SmartCardPlugin’, which is given to us from the site as an .MSI File in the case of Windows users. This plug-in actually forms the bridge, between their Web-application and the recognized card reader.
While this system seems to work quite well, based on my first use today, I would say it represents bad programming aesthetics. Even though the actual software-components were provided by Xerox, this system does not install a PKCS#11 security device, nor anything approaching a CAC card reader, with PKI. Instead, this service is based on an .EXE File, and leaves its hook in our browser, which in the case of Firefox, we can find under Tools -> Options -> Applications.
What this means is that the site will display an Web-object, that needs to be ‘opened’ by a specific application, associated by the Web-browser.
The most positive aspect to how this works seems to be, that indeed, it provides compatibility with Firefox, Chrome, IE etc..
But instead of providing strong security, this method is only as secure as the SSL connection to the site.
It may be interesting to note, that even when this system was based on Java, none of the officials ever promised that it would work under Linux, so I see no loss there.
Some users have complained, in that this system fails to meet their expectations, in one day combining the payment service as a smart-phone, NFC service. I have to concur with this hope. I also find it a bit clumsy right now, to have to plug in my Opus Card into a USB port, and to open a site which asks me for my payment credentials – ‘the old-fashioned way’.
But OTOH, I do not see much of a practical loss, compared with how it used to work. And one reason the officials may be doing it this way, could be a negative prognosis for the future of Java itself.
It just so happens that I prefer proven standards.
Continue reading Opus En Ligne