A few months ago I noticed that my iPhone Visual Voicemail was not working reliably. Most of the time messages kicked into the standard NTT docomo dial-in messaging service (1417). I didn’t pay it much mind until December when I had a lot of job related back and forth with missed calls showing in the docomo SNS feed but nothing ever showing in Visual Voicemail.
Today I finally called docomo support and got a quick answer:
“Are you using the latest iOS update?”
Of course I am.
“NTT docomo recognizes the problem and is working on the Visual Voicemail issue. When Apple releases the new update please install it and let us know if it doesn’t solve the issue.”
Okay, that sounds like a plan. Hopefully iOS 15.3 will fix the NTT Docomo Visual Voicemail issue. Until then NTT Docomo iPhone users will have to use the dedicated 1417 dial-in message if Visual Voicemail is not working. Judging from the quick support response it sounds like a widespread issue.
Update: good news, iOS 15.3 updates fixes the Visual Voicemail problem for docomo iPhone users.
After many years of rumors Google finally unveiled their custom silicon, though details won’t be known until Pixel 6 devices go on sale. Dieter Bohn wrote:
Tensor is an SoC, not a single processor. And so while it’s fair to call it Google-designed, it’s also still unclear which components are Google-made and which are licensed from others. Two things are definitely coming from Google: a mobile TPU for AI operations and a new Titan M2 chip for security. The rest, including the CPU, GPU, and 5G modem, are all still a mystery.
On the NFC hardware side everything has been ready to go on all smartphone hardware for years because NFC A-B-F support is a requirement for NFC certification. The problem has been on the SE side, the black box where all the transaction magic happens. From GlobalPlatform the SE certification organization:
A SE is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (for example cryptographic keys) in accordance with the rules and security requirements set by well-identified trusted authorities.
There are different form factors of SE: embedded and integrated SEs, SIM/UICC, smart microSD as well as smart cards. SEs exist in different form factors to address the requirements of different business implementations and market needs.
SE Wars In the pre-Apple Pay mobile carrier hardware era, carriers used SE SIM or a embedded Secure Element (eSE) + carrier SIM combo that chained customers to service contracts for the privilege of using mobile payments. This is the classic Osaifu Keitai model pioneered by NTT DOCOMO: an overpriced carrier SIM contract to use mobile payments only with select carrier handsets.
This carrier lock in model is one reason why Mobile FeliCa ended up being ridiculed as ‘galapagos technology’ even though everybody else copied it. This carrier SE SIM hostage situation, i.e. the Mobile Wallet SE Wars, led Apple and Google to follow different strategies to address the problem.
The Apple Pay Way Apple’s answer of course was Apple Pay. A unique in-house strategy of putting a GlobalPlatform certified Secure Element in Apple Silicon. Most eSE go on the NFC controller, but doing it the Apple in-house way has advantages over a NFC chip vendor bundle: control of the eSE applets and ability to update them and the Apple eSE for new protocols in iOS updates. We saw this in action with the addition of FeliCa in 2016, PBOC in 2017 and MIFARE in 2018. We are seeing it again with the addition of Ultra Wideband (UWB) Touchless in iOS 15.
The Google Pay Way Google’s answer to the carrier owned SE problem was a convoluted evolution from Google Wallet (2011) to Android Pay (2015) and finally Google Pay (2018). Google’s first salvo was Host Card Emulation (HCE): “NFC card emulation without a hardware secure element” a virtual secure element hosted on Google’s cloud or in an app. Later on Google attempted to do the same for FeliCa with HCE-F.
The HCE strategy was quietly abandoned when Google decided to get into the hardware business and Android Pay turned into Google Pay. Now we have Google Pay running on Google Pixel with its own embedded Secure Element (eSE). With Pixel and Google Pay, Google decided they didn’t want to be the Secure Element provider for every Android OEM out there especially when the Chinese OEMS are all rolling their own eSE based digital wallet services anyway, completely ignoring HCE. Sure, HCE/HCE-F is still there in Android developer documentation but it’s a vestigial relic of the SE wars. From an industry standpoint it’s eSE or nothing now.
Google Pixel models up to now have used vendor bundled eSE + NFC controllers with the Pixel JP models using the Osaifu Keitai software stack. This makes global NFC support more complicated because Google doesn’t ‘own’ the eSE and the software stack, at least not in the Apple sense of making their own all in one solution. As we have seen, Mobile FeliCa is installed on all Pixel 5 models but the Osaifu Keitai stack only loads on JP models.
Will a Tensor SoC that contains a Titan M2 and a custom eSE solve this? It all depends on whether Google goes deep instead of cheap by stripping Google Pay of its dependency on the Osaifu Keitai stack and create their own region free support stack. If so, inbound Pixel 6 users will have the ability to add Suica and other FeliCa cards out of the box.
The PASPY organ transplant
As pointed out previously, the PASPY transit card transition from NFC to QR is not going to be easy. Not only does HIroden have to swap out the basic technology infrastructure, they also have to swap out their IT system integrator partners. The PASPY system was built and is currently managed by NEC with the last server upgrade completed in 2014. A quick look at the system map illustrates the pain points that including swapping out the NFC reader infrastructure in trolleys and buses and replacing it with QR readers with mobile connectivity, a requirement because of central processing. There will also be a lot of pain for wide area commuters because going QR means cutting the cross compatibility cord with ICOCA, Suica, etc.
The mobile connection means a mobile operator has to be involved to make it work. The likely IT system candidate here is the same one behind all the QR transit systems in Japan so far: SoftBank backed QUADRAC. The PASPY QR replacement is expected to be closed loop, similar to the QR + smartphone app closed loop system being tested by Nankai. Too bad JR West can’t come to the rescue with a localized version of the Suica 2 in 1 Region Affiliate Transit Card, but that’s another story for another time.
To eSIM or not to eSIM
eSIMs are great in theory, unfortunately the current reality for Japanese customers is less than ideal even thought the Japanese Ministry of Internal Affairs and Communications (MIC) is promoting them over traditional physical carrier SIMS and issued eSIM guidance. In addition to this carrier SIM locked devices will not be allowed from October. Of the big three carrier budget brands: NTT DOCOMO (ahamo), au KDDI (povo), SoftBank (LINEMO), only LINEMO and povo offer eSIM options. DOCOMO says they are thinking about it but for now ahamo is a physical SIM service because DOCOMO says eSIMS are not as secure as physical SIMS.
A recent article by Masao Sano outlined the eSIM situation in Japan and current obstacles for customers. The online signup process and device setup isn’t always smooth going and first time customers sometimes have to deal with unlocking their carrier device, APN settings, network authentication codes, profile installations and so-on. The eSIM process needs to be easier and user friendly. The good news is that unlocked carrier phones will be standard soon along with better eSIM option plans and migration setup. Once ahamo adds an eSIM option the next step will be taking it mainstream for major brand carrier contracts.
Apple Music finally sorts Japanese artist names correctly
Seriously though I wonder what took Apple so long to fix most, but not all, of their Japanese music metadata mess. Not a moment too soon as the old reliable iTunes Match service seems to be on its last legs and the macOS Music app replacement for the old reliable iTunes app is completely useless for organizing a digital music collection: Apple Music and iCloud Music library have a mind of their own.
Truth be told, I had more fun collecting and listening to music on iTunes + iPod than discovering music on Apple Music + iPhone. For some strange reason, less is sometimes more.
The Weekly will be taking a summer break the weeks of August 9 and 16 and resume the week of September 1. Take care and enjoy the rest of the summer.
NTT FLET’S internet service has been around forever in many configurations, the latest being Flet’s Hikari ‘optical fiber’. I call it flexible fiber because NTT uses the term Hikari when they should not. My Hikari only comes into the apartment building junction box then branches into each apartment with good old cooper wire phone lines and a VDSL modem. NTT calls that Hikari, I don’t.
PPPoE/IPv4 traffic has been tapped out in Tokyo since at least 2017. When I first upgraded from PPPoE/IPv4 to IPoE/IPv6, I saw a pleasant bump in speed with none of the night time internet traffic meltdowns when using PPPoE.
I thought my problems were solved but over time IPoE/IPv6 download speed has slowed down while iPhone NTT Docomo 4G LTE speed has skyrocketed past NTT Flet’s:
A year ago Twitter user shao, who posts wonderful network and payment tech tweets with the deep tech background to back them up, noted that the Japanese Internet Provider Association was in a collective hissy fit with NTT. IPoE/IPv6 junction points to NTT main lines where tapping out and providers needed more junction points, they also wanted IPoE access pricing brought in line with PPPoE and better traffic control. NTT gave internet providers the cold shoulder with ‘we’ll consider it if you do the work.’ The result of that is NTT East/West Flet’s service is seriously slowing down in face of stay home telework, bored kids streaming content and too much online shopping.
As shao notes 4G and KDDI au Hikari nuro service are, so far, unaffected. The strange thing here is that KDDI is simply renting NTT dark fiber for nuro. So yes, NTT has the capacity, but doesn’t seem inclined to put in the effort to share it unless providers do the work, and also pay up. To be fair I think one of the problems is hinted at in a recent annual NTT financial report: a shortage of field engineers and technicians. Somehow it seems fitting that the human problem of Covid is also the human problem of slow internet speeds.
Convenience store self checkout all have the same deal: scan with barcode reader, tap some choices on the checkout touchscreen, scan a rewards card and pay with Apple Pay Suica, etc. The stationary barcode readers at JR East station NewDays are slightly better but you still have the touchscreen to deal with.
Barcode app and plastic variety reward cards were already a pain in the ass before all the fun started and are worse now. Apple VAS and Google Pay Smart Tap for NFC contactless reward cards has been in place for some time but uptake in Japan has been slow and small. So far only 3 contactless NFC point cards exist: Docomo dPOINT, T-Point and PONTA, and only 2 places use them: LAWSON (dPOINT and PONTA) and Tsutaya (T-Point). Part of the problem is that VAS/Smart Tap support depends on 2 factors: the reader and the POS system.
Most modern NFC readers support Apple and Google protocols but POS system support is another matter. Pre-packaged POS system providers like AirPay and J-Mups that are popular with smaller merchants don’t support them yet. This means that only big retailers with deep POS development resources like LAWSON (Mitsubishi Corp group) have added NFC contactless reward card support so far.
Apple Pay Japan supports dPOINT and PONTA cards but there are subtle differences: PONTA card requires Face/Touch ID authentication, dPOINT does not. I have not fully tested dPOINT for point payment but suspect authentication is not required for getting points but required for paying with points. One hopes that with the Covid-19 crisis in full swing, retailers and card empires (JRE Card, etc.) have the incentive to provide customers with the safest contactless experience for both payments and reward cards.
When iPhone X came out in November 2017, IT journalist Tsutsumu Ishikawa named Suica the Apple Pay winner. What he really meant to say was that Suica Express Transit was the only easy way to use Face ID Apple Pay. It took me a long time to get used to Face ID Apple Pay but now with the COVDID-19 crisis and regulation face masks, the choices are back at square one: (1) yank down the face mask to Face ID anything, (2) use a passcode instead, (3) use Apple Pay Suica set with Express Transit. Yeah, the last one. More people have Express Transit now in China, TfL-land and little bits of the MTA OMNY system but nobody has it for purchases. Except Apple Pay Suica, still the only Express Transit card for contactless payments at stores.
In the sudden era of face masks and plastic curtained checkout areas, dealing with Face ID as little as possible, and using Apple Pay Suica as much as possible, makes life easier and safer: experts in Japan instruct people not to touch face mask surfaces and you don’t want to be yanking down a face mask to use Face ID Apple Pay at close proximity checkout. The interim solution is Apple Pay on Apple Watch which does not use Face/Touch ID at all. But there is that social distance problem: your arm has to reach the reader. That’s the thing about NFC, it’s close proximity technology. So are QR Codes.
The Touchless Distance When I first saw the NTT Docomo Ultra Wideband Touchless Mobile FeliCa demo I though why would anybody want to pay a few feet away from the reader? Outside of paying while sitting in the drive thru I could not think of a reason. After living with Face ID, face masks and COVID-19 social distancing, I see the reason now at every checkout at every store. I want it. You will too (the 1:20 mark):
And for cars too, CarKey will work like this at some point (0:13 mark):
Touchless Transit Gate vs Facial Recognition The COVID-19 crisis upends another Face ID related technology fantasy: facial recognition transit gates. NEC is working on face recognition that works with face masks. If anybody can deliver viable face recognition with face masks NEC will certainly be one of the first, but there are cost, performance and privacy issues to consider for transit gates: how fast is the transaction speed, how well does it scale for commuter rush, how do you register faces? Who controls all that transit gate face data and is it stored domestically or data farmed out internationally?
Mobile FeliCa and MIFARE Touchless is the same device level security model we have now with Apple Pay Suica and Student ID, and what we will have with CarKey and shared ‘keys’. UWB is a new hardware layer on top of what already exists, it bridges the NFC infrastructure and contactless payment methods we have now and extends it to the future instead of junking it.
Osaka Metro plans to have face recognition transit gates deployed in time for Osaka Expo 2025. It’s a risky transition plan. Touchless transit gates are the safer bet. Sony, Docomo, NXP, JR East, JREM are doing the necessary hardware and software development with the same embedded secure element security and local processing architecture we have now. Osaka Metro can buy the finished goods from them instead of reinventing the wheel.
Fixing Face ID Shortcomings On the smartphone side Apple already has the Ultra Wideband U1 chip in iPhone 11. The next step is Apple Pay support as outlined in the iOS 14 Apple Pay post. I hope Apple uses the opportunity of adding UWB Touchless Apple Pay to enhance Face ID with improved technology and controls. Express Card/Express Transit is the Apple Pay method to bypass Face/Touch ID for transit, purchases (Suica) and ID door access (Student ID and CarKey). Extending the Express Card/Express Transit model as much as possible, while keeping the high level of security, is one practical way Apple Pay can address some of the Face ID in face mask era pain points.
Last but not least I don’t see Open Loop transit ever working with Touchless technology. Open Loop will likely remain a NFC only service because EMVCo partners are invested in lower common hardware standards like ISO14443 and plastic cards and probably loath to update them. Certainly they don’t want to lose the plastic card issue business because it’s more profitable than issuing digital ones. EMVCo certainly didn’t see the current situation coming, nor did Apple of course. But then again who did?
iOS 13.5 Face ID tweak iOS 13.5 beta 3 has a Face ID tweak: when it detects a face mask it no longer delays the swipe up Passcode pop up with a 2nd read attempt, it goes straight to Passcode pop up. This small tweak remove a tiny bit of Face ID with face mask stress, but tiny things add up when unlocking iPhone many times a day. But for me Passcode pop up was only one stumbling block, a second bigger stumbling block is Passcode entry via the numeric keyboard.
There is a curious lag between what your fingers are tapping, the feedback click sound and what tap the iPhone actually registers. If you closely inspect the visual tap feedback, it flashes white then fades slowly, while the click just clicks.Taken all together, my brain wants to type fast and tells me the my 2 thumb input is going fast, but the iPhone Passcode numeric keyboard wants me to type slow with 1 thumb. Perhaps it’s just me but I only get correct passcode entry 50% of the time unless I slow way down and type with 1 thumb.
Overall the Face ID with face mask tweak seems more for iPhone unlock, it’s much less useful for Apple Pay. I hope Apple continues to tweak Face ID before iOS 13.5 ships but the reality is Apple can’t do very much in a short time.
John Gruber had an interesting observation regarding another iOS 13.5 beta 3 tweak, this one for Group FaceTime:
methinks a lot of folks at Apple (executives included) are using group FaceTime chats more than ever before lately, and have realized that in practice, especially in larger groups, it’s not a good experience.
Unfortunately it’s the same for Face ID: Apple is only addressing it because Apple execs are wearing face masks. It’s very frustrating that Apple is only dealing with the Face ID with face mask issue now that it’s on their face. Customers in Asia have been wrestling with it since iPhone X day one November 2017. At any rate I hope Apple puts the experience to good use for a better future version of Face ID.
The return of Touch ID? The release of iPhone SE and iPad Air with Touch ID on the power button has some tech bloggers speculating if this means a dual biometric approach for future iPhone models. I don’t think so.