Apple Maps Japan mislabels cemeteries, digs own grave

Dear Apple Maps JP team: this cute rabbit stone lantern in front of Myohoji temple main hall is not the cemetery

In the latest Apple Maps Japan installment of how not to run a digital service, we can now add graveyards to the long list of things done poorly or incompetently. About a month ago I noticed new Point of Interest icons appearing on temple buildings close to traditional ‘manji’ Buddhist temple Point of Interest icon marks. The new POI is a western style gravestone with a flower, but the new icon names are in English, not Japanese. As they appeared to be duplicate Point of Interest information I reported them as duplicates which is not easy to do in the current Apple Map problem report mechanism.

Soon the new icons were everywhere and I realized that Apple Maps was attempting to mark cemeteries inside temple compounds but making a mess of it: randomly labeling temple halls as cemeteries instead of correctly identifying cemetery areas in temple compounds or nearby in separate plots of land. As you might expect there are also problems with the POI information, web links don’t always work, addresses are incorrect for contacting cemetery offices, etc. And then there are user ratings.

As a rule Apple Maps locks user ratings for public and religious institutions, limiting them to places of business (restaurants, etc.). This is the sensible and right thing to do. Unfortunately the new cemetery POI allows user ratings. I can only imagine this is a system error that needs to be fixed.

The whole affair is classic Apple Maps Japan: Apple signs up a new POI data provider but doesn’t vet any of the data quality, loads it into the system and boom. Duplicates and mistakes all over the place, literally, that can stick around for years. Currently Myohoji temple in Koenji has: 2 manji POI, one from Recruit Jalan that marks the temple office, one from another public based source that marks the cemetery, and 1 new English only cemetery POI icon that marks a nice little stone lantern in front of the main hall.

It’s a mess that could have been avoided with a minimal amount of data verification and vetting, not even checking to make sure the data is localized for Japanese. Wasn’t the new Apple Maps supposed to fix this? I guess Apple doesn’t consider it a problem. I say it again, the more I use iOS 15 Apple Maps, the less I like it.

Real world Eki-Net impressions

I finally had the chance to use Eki-Net app, aka Eki-Net 2, eTickets (JR East Shinkansen) and Ticketless (JR East Express Trains) reservations on several trips recently, a real world workout. After a shaky launch in March 2020, followed by a major system upgrade in June of this year, the foundation is in place and JR East is going all out to promote Eki-Net for the year-end travel season that will see a considerable uptick compared to last year’s ‘stay home’ and stew regimen. I posted an Eki-Net 2 overview in June that covers the basics, this post is a short followup of impressions.

Using Eki-Net eTickets at the transit gate is clean and easy as the JR East promo videos. The messy part is creating an Eki-Net Japanese online account that is completely separate from your Mobile Suica account and your JRE POINT account. They all link together but are all separate with separate login names and passwords. This is the weak point of using JR East online services, there is no single master login system ID service like Apple ID or Google Account.

Once the Eki-Net online account is setup, with a VIEW credit card duly registered for maximum JRE POINT, using the bare-bone iOS Eki-Net app is a snap. Japanese user reviews of the Eki-Net app are overwhelming negative, but I found the app covers the basics well enough for what it is designed for: finding a discount reservation for your travel date, choosing a seat, purchasing the eTicket and assigning it to a designated Apple Pay Suica (or PASMO) card, or cards if your are purchasing for more than one. Group eTicket purchase and Transit IC card assignment are very convenient features.

My only real quibbles of using Eki-Net boil down to two feature requests.

  • Apple Pay Support: back in the Suica App Shinkansen eTicket days, you could purchase tickets using Apple Pay or the Suica App registered credit card. Both were convenient. Eki-Net does not support in-app Apple Pay. You make purchases with the app and have to confirm the purchase with the registered card CVV number for security purposes…a pain in the butt, pull out the physical card every time because I never can remember the code. Apple Pay in-app purchase would be great to have and it should be easy enough to arrange the backend so that Apple Pay VIEW purchases earn JRE POINT automatically.
  • Notifications: in the current version of Eki-Net (v2.1.5) train time notifications are basically email only, once when you make the reservation, another email before train departure and a final email notification when the assigned Apple Pay Suica card or equivilant goes through the Shinkansen gate. There is a link to add the ticket train boarding day/time as a calendar event that does in a pinch, but I would also like to have regular and robust native iOS notification support. For me there is nothing so handy as Apple Watch haptic notifications.

Eki-Net works well enough as is, but having Apple Pay in-app support and iOS notifications would significantly improve the app experience. There is a lot of room for other improvements: it would be great to have smooth integration with other eTicketing services for private rail and other JR Group companies (EX, etc.). Suica is celebrating it’s 20th anniversary this year, Eki-Net is at anniversary #21. The current state of Eki-Net App and eTicketing makes it clear the mobile ticketing journey is just beginning.

Mobile FeliCa evolution: FeliCa without the FeliCa chip

FeliCa Dude did his usual public service of posting Mobile FeliCa details for the latest Pixel 6 devices. There wasn’t any change from Pixel 5, so no global NFC Pixel for inbound visitors. Nevertheless it’s a good opportunity to review some important recent developments that have taken place behind the scenes on the Android Mobile FeliCa side and examine some possible 2022 scenarios. Things have changed even if most users don’t notice any difference.

The chart outlines Mobile FeliCa on Google Pixel developments based on information from FeliCa Dude’s tweets.

Mobile FeliCa 4.0 (Pixel 4) freed Android device manufacturers from having to use embedded secure element + NFC chips from the FeliCa Networks supply chain. Any FAST certified secure element will do. This development has resulted in a number of inexpensive Osaifu-Keitai SIM-Free smartphones released by Chinese manufacturers recently that are selling well. Hopefully it will have wider implications for inexpensive global NFC Android devices. There are lots of people in Hong Kong who would buy one to use Octopus.

Mobile FeliCa 4.1 (Pixel 5/Pixel 6) introduced multiple secure element domains. This allows the device manufacturer to ‘own’ the eSE and load or delete Java Card applets. FeliCa Dude thinks that multiple secure element domains (MSED) might play a part in the MIC digital My Number Card due to launch on Osaifu Keitai devices in 2022. My Number card uses NFC-B but MSED allows the Mobile FeliCa secure element to host it anyway, an interesting development.

Mobile FeliCa 4.2 or 5.0? The next version of Mobile FeliCa (MF) will hopefully support FeliCa SD2 next generation features that shipped in November 2020, features that power Suica 2 in 1 Region Affiliate Transit Cards (aka Super Suica) which are going wide in March 2022. These cards really need to be on mobile for future MaaS service plans outlined by JR East which cannot happen until SD2 features are added.

The improvements in MF 4.1 certainly give Android device manufacturers the ability to update MF over the air but don’t hold your breath. Standard industry practice to date has been ‘buy a new device to get new features’. Apple has been a little bit better in this regard: MIFARE support was added in iOS 12 for Student ID cards and iOS 15 fixed some Calypso bugs on ‌iPhone‌ XR/XS and ‌iPhone‌ SE.

A FeliCa Dude Reddit post comment regarding Asus smartphones illustrates the pre-MF 4.0 situation: “any phone that lists ‘NFC’ compliance must support Type F (FeliCa), but as there is no Osaifu-Keitai secure element <aka Mobile FeliCa secure element>, you will be limited to reading and potentially charging physical cards: you cannot use the phone as a card itself.” That was then, this is now.

Most people assume FeliCa support requires a Felica chip but this is not true. The evolution of hardware independent Mobile FeliCa is very clear: the ‘FeliCa chip’ from Sony/FeliCa Networks requirement is long dead and gone. Manufacturers like Xiaomi claim they make special models and add FeliCa chips just for the Japanese market, but that’s just marketing BS: they run Mobile FeliCa on the same NXP NFC chipset they sell everywhere. The majority of smartphones supporting FeliCa don’t have a FeliCa chip, everything from EMV to FeliCa and MIFARE runs on any GlobalPlatform certified secure element on any Android device.

Hopefully the sum of recent Mobile FeliCa developments, along with Garmin Suica, Fitbit Suica and built in WearOS Suica showing up in recent developer builds, indicate that FeliCa Osaifu Keitai services will become standard on Android devices as they have been on all iOS and watchOS devices since 2017.

The Apple Pay whipping post

I suppose I should care about the latest ‘Apple Pay is evil’ brouhaha piece by CNBC “Apple is sticking taxpayers with part of the bill for rollout of tech giant’s digital ID card” by Hugh Son and Kif Leswing which appeared more or less at the same instant as “What Apple’s Secret DMV Contracts Tell Us” on Jason Mikula’s Fintech Business Weekly Substack newsletter.

But I don’t. In this age of shut up when we tell you to shut up big corporate and social media, I get suspicious when east coast journalists start trolling a big new ‘scoop’ at the same time. Why now and why these guys? Why do they ask the same questions? Do they hang out at the same bar and share story notes, or did somebody feed them the story and the sources? Both pieces outline some of the agreements Apple made with states and the restrictions/conditions Apple has in place to provide ID in Wallet for driver’s licenses.

When a story like this breaks from multiple outlets just before a service launch, and there is every indication Apple plans to release ID in Wallet with the iOS 15.2 update, I smell somebody’s agenda. A somebody who wants to upend Apple Pay’s ID in Wallet launch cart. This is the way to do it.

As Mikula is a former Goldman Sachs guy where he learned how to fleece things, he provides important context to the story that CNBC does not:

Multiple ID verification (“IDV”)…is big business — according to a company in the space, Mitek Systems, it was worth an estimated $7.6 billion in 2020 and will grow to nearly $16 billion by 2025. Socure, a company offering IDV services, just raised $450m at a $4.5 billion valuation — an increase in value of ~2.5x from earlier this year.

What Apple’s Secret DMV Contracts Tell Us

I wrote about iOS 15 ID in Wallet earlier this year:

There is another aspect to consider, one that Apple certainly won’t divulge: who manages and runs the backend centralized mobile ID issue service that plugs into Apple Pay servers…There has to be a partner service company that sub-contracts mobile ID issue services to participating state governments…somebody that does the heavy lifting of linking various state database servers to provide a centralized card issuing service so that Apple can provide a seamless ID add card experience. But it must be an independent entity that can provide the same set of backend ID issue services to other digital wallet platforms (Google Pay, Samsung Pay, etc.) at some point. Because if it is not an independent entity providing those services, Apple is inviting more claims that Apple Pay is a monopoly. It’s a mystery worth digging into.

Secrets of iOS 15 Apple Wallet

Beyond defining Digital Identity Credentials that are the key part of the ‘restrictive’ agreements between the states and Apple, there are no system details. Nada. Certainly nothing like the system diagram from the Japanese Ministry of Internal Affairs and Communications (MIC) English PDF document: First Summary Toward the Realization of Electronic Certificates for Smartphones, that outlines how the digital ID system architecture for the Individual Number Card (My Number) works. A white paper from Apple explaining how ID in Wallet works both on the device and in the cloud, is key to understanding how secure ID in Wallet is, and how restrictive the agreements are. Without one, Apple puts itself, and Apple Pay ID in Wallet at risk in the political environment that is state government contractor relations. Asking users to simply trust a black box doesn’t fly in this security risk adverse, privacy conscious age.

As nothing has been released yet, and we have no white paper or anything else from Apple, I think discussion is pointless at this point. Questions are a good thing but are CNBC and Mikula asking good questions? I think the sudden ‘we’re protecting the tax payers and good citizens’ angle is highly suspect when CNBC has been a highly partisan mouthpiece always on the side of establishment government and establishment corporate America… a media company who asked nothing about big pharma’s role in the COVID hysteria driven vaccination program for example, or why Pfizer etc. are exempt for any and all side-effects of their experimental vaccinations, all while demonizing the good citizens who want those questions asked.

After all, privatization of government services is so entrenched at this point nobody really questions it anymore. Wouldn’t it be better to ask why states want to sign up for ID in Wallet, what they want to get out of it and why, why, why? Could it be that states want a successful digital ID service people will actually use? Not sexy enough I guess. If you ask me, I think some government contractor in the IDV business, and their supporters, stand to loose out in a big way if ID in Wallet is a success and used some connections to slam a media outrage ball into Apple’s court. Let the games begin.

OMNY card completes the EMV only OMNY system (updated for Apple Pay OMNY)

After a long gestation, and a COVID related delay, the good old swipe MetroCard replacement has finally shipped. OMNY card: a ‘truth in the cloud’ EMV bank payment card, not a MIFARE or FeliCa ‘truth in the card ‘ smartcard like London Oyster or Tokyo Suica. As MetroCard missed the transit smartcard revolution of the early 2000’s, MTA and ticketing system management company Cubic Transportation Systems decided to go all in with a new system built on EMV and open loop, i.e. using ‘open payment‘ EMV contactless credit/debit cards for transit fare foundation instead of dedicated transit cards. It’s a ‘one size fits all’ approach where bank payments cards are promoted for every kind of purchase. The coming addition of fare capping, i.e. OMNY card features without OMNY card, further reduces the need for OMNY card commuter passes and encourages credit/debit card use.

The piecemeal OMNY rollout has not been an easy transition for MetroCard users. One problem with one size fits all open loop is that different people have different needs: minors, seniors, disabled, daily commuters with set routes, people without credit cards and so on. Even with fare capping open loop cannot handle these well, if it did TfL would have killed Oyster card long ago. Hence OMNY card is a closed loop OMNY branded EMV card with CVV security number, likely from a Mastercard issuing agency, similar to the Mastercard closed loop Ventra and Opal digital cards. Like Ventra card, OMNY card comes in plastic and the digital version will come to Apple Pay and Google Pay ‘soon’, although MTA has not given any launch window for OMNY iOS and Android apps that will be necessary for adding OMNY to Wallet and for recharge.

As most of the open loop systems in North America, UK and Australia are designed and managed by Cubic it’s helpful to compare their ticketing system profiles.

When you carefully analyze the different systems and Express Mode transit support listed on the Where you can ride transit using Apple Pay support page, one condition becomes clear: current transit systems do not support Apple Pay Transit cards and EMV Express Transit when the system uses both MIFARE and EMV open loop. It’s a choice between supporting one or the other, not both. I suspect Apple does this because of the complexity supporting MIFARE and EMV mixed mode operations on the same transit system.

OMNY is a new system however, built completely on EMV and EMV only. When Apple Pay OMNY launches, OMNY will be the first system to support both EMV as an Apple Pay transit card and EMV Express Transit mode for credit/debit cards. There is a catch however similar to using Apple Pay China T-Union cards: turning on one card for Express Transit turns off other cards. This happens when cards share the same NFC ID number which would result in card clash at the gate reader. When cards share the same ID, only one card can be set for Express Transit mode at any one time. For EMV cards this applies to payment cards as well so Express Transit Card settings will likely turn off any activated payment cards when an OMNY card to turned on, and vice versa.

After OMNY card is launched on Apple Pay and Google Pay, the next OMNY challenge will be integrating Metro-North and LIRR commuter rail ticketing. A difficult task as none of the train line are equipped with NFC card readers. MTA has yet to unveil any commuter rail ticketing integration details. Ventra has the same problem, commuter rail ticketing remains the age old conductor visual inspection, no tap and go contactless for you. And as ever there are thorny open loop user data privacy issues.

OMNY truly represents the state American public transit as it tries to get on board with mobile payments. Progress is good and welcome but a real next generation vision with meaningful forward development of American public transit will continue to be a confused mess despite endless broken promises to fix it…simply because people with money and means don’t use it. If they did, things would have been fixed long ago.