Quick note that Ben Whitaker (me) will be speaking briefly at Mobile World Congress in Barcelona just after 15:00 on Tuesday 12th Feb at the Mobile Innovation Market Place in Hall 2, Auditorium B.
This is thanks to Masabi being nominated as a "Top Innovator"
For people that can't make it, the slides and speaker notes look something like the following:
Our applications are built on three core principals –
Make the application USABLE and relevant to the end user, and make the default use cases quick and easy on the mobile. (I’ll show you some of that later)
Then, PORTABILITY to all popular handsets, including the older handsets that many developers avoid, to ensure the largest possible user-base for your service.
And for Mobile commerce – SECURITY, on all phones, to modern public standards.
Most Data passed through standard GSM services will not be secured to meet Financial Services or Payment Card Industry regulations.
You shouldn’t use SMS or WAP to send payment instructions, bank passwords or credit card details from the phone because too many individuals can gain access to them in transit.
(True end-to-end https is only available on the latest handsets – slow and not usable from Java or SMS.)
"The contents of SMS messages are known to the network operator's systems and personnel. Therefore, SMS is not an appropriate technology for secure communications. Most users do not realise how easy it may be to intercept“
Nick Jones, Gartner Research 2002
We built EncryptME to the latest standards for new secure web services, and it is still the world’s only US Government Certified mobile java security library.
At 3kb, it can provide security on the oldest java handsets, including the black and white Nokia 6310i (show legendary retro business phone)
Most importantly, it allows SMS data to be encrypted too!
(Hold up 3510i)
When you provide transactional software for these old phones, we find that significant numbers of people use them. Can you afford to throw away 10-20% of your users?
(By way of comparison Microsoft and iPhones represent around 1% of the market - they may be heavier data users, but others use data too)
To provide Portability, we use our own porting Framework: DevelopME
We’ve seen many mobile products that are either attractive, but high-end only; or basic-looking and available on all handsets.
Through DevelopME we are able to provide attractive apps on all Java phones.
You have to work hard to build full function applications that work on the older phones, and you can’t out-source it, or think about it late in your dev cycle – it has to be at the core of how you build everything.
It’s not just different graphics sizes and bugs, you have to build variations of UIs that make the best use of very different input mechanisms on the different phones, and not expect the end consumer to re-learn new UI concepts that they don’t already use on their phone every day.
[The screenshots above are animated, to show useful UI widgets helping the user to select from large lists, or input Credit Card numbers correctly]
WAP and WEB services are Thin Clients ; good when you have a reliable, low latency connection.
Mobile is not like that – inside buildings, moving vehicles and in remote locations connections are often dropped or unavailable.
Mobile Java allows us to build FAT clients, and not just glorified mini-browsers!
Applications should provide most of the interaction while OFF-LINE and then only require an occasional connection at the end to make transactions, or get updates.
e.g. you should be able to review your bank account and create new payment instructions while on the metro, not only when stood still in good
Here are screenshots showing how you can quickly select one station from a list hundreds long, and also how to perform local validation of credit card numbers before sending to reduce the number of unecessary network connections
SMS Failover:
Many users cannot make network connections from Java using WAP, because they need to switch to the correct INTERNET settings.
To provide these users with an out-of-the-box instant purchase, the application can automatically detect the lack of functioning GPRS and switch to encrypted SMS instead.
Ported to over 750 handsets, multiple languages, alphabets, brands, currencies.
Live around the world.
Full sign up, credit cards and bank transfers from the phone – no need for PC.
Managed upgrade process, add new payment methods or anti-fraud methods without upgrading the application, dynamic download catalogue, news alerts, etc even on the venerable 3510i.
Credit Card details entered just once into the application.
Users have said “easier to use the mobile purchase than web purchase” because of quick, optimised workflow.
We’re using on-screen barcodes to show the ticket values for reading by automatic gates, or checking by the train guards who carry hand-held scanners.
The ticket code can be transferred to the NFC element on compatible phones (like this Nokia 6131NFC) but this handset is the only widely available GSM handset with NFC and we’ve not heard of other mainstream devices in the pipeline.
Even when NFC services become mainstream, you will still need a secure interface to purchase entitlements, before they get transferred to the NFC element.
Simple – put in your car, your credit card, and how long you want to park.
Brand new user can sign up and pay in just one secure SMS (or 0.02pence worth of data)
Extend your parking without returning to the vehicle.
As Gartner point out, SMS are more easy to intercept than most people think, and for many professions that is not a good thing.
We can extend SMS quickly and simply for Operators and Businesses to provide confidential SMS only readable by the intended recipient, using public/private RSA encryption at Government approved strengths.
Come see me after for live demos,
or to chat about building secure mobile applications for:
m-commerce,
Banking,
Ticketing,
Messaging.
