24 Nov

US Mobile Market Update – Q3 2015 (Chetan Sharma)

Screen Shot 2015-11-24 at 9.55.07 AM

Check out Chetan’s latest report, US Mobile Market Update – Q3 2015. Some highlights below. More details are available at: http://chetansharma.com/connectedconsumer15.htm.

Handsets – As expected, (a) Smartphones continue to rule, with penetration in the US now at 78%! (b) On the opposite end, feature phones are becoming extinct.

Android vs. iOS: The fight for profit continues – Chetan’s report shows that Apple continues to dominate the market with 80% of the profit share, 40% of the revenue share, with only 14% of the unit share. This is in contrast to Android where its OEMs such as HTC, Sony, LG and Lenovo all lost money in their device business; if we don’t count Samsung, Android OEMs made around billion dollars (despite over $26 billion in revenues). Chetan attributes this to the difficulty in differentiating on an open platform, which I agree with.

Other – Annual household spent on Mobile data is approaching $1,000, with mobile data spend rising while landline voice has declined. In addition, cellular voice spend has also gone down. Complementing the fact above that feature phones are becoming extinct, US consumers will spend more on wearables than on feature phones in 2015. Other interesting pieces of info: number of connected devices per US household is now 5.3 with over 37% of the households in the 4-8 range, and almost 6% of the households have 15 or more connected devices.

So in summary, the US and the whole world continues its path to always connected — with the mobile device at the center of how information is retrieved and how we connect with others. The mobile device is the world’s most important social artifact, ever. Those (companies) that have not yet embraced digital and mobile, are today’s dinosaurs.

Related to this, see Fortune’s article To Grow, Mobile Operators Must Look Beyond Phones.


14 Sep

Getting ready for the new iOS 9 ATS feature

With the goal of enforcing best practices for secure network connections, iOS 9 introduces new security requirements and behavior with its new App Transport Security (ATS) feature.

If you are not planning to recompile your apps with Apple’s iOS 9 SDK (or Xcode 7), you do not need to make any changes. But if you do recompile your app, not following the new security requirements will result in connection failures.

To comply with the iOS 9 ATS security requirements, your app network communication must:

(Source: iOS 9 documentation)

  • The server must support at least Transport Layer Security (TLS) protocol version 1.2. This is the default behavior.
  • Connection ciphers are limited to those that provide forward secrecy (see App Transport Security documentation).
  • Certificates must be signed using a SHA256 or better signature hash algorithm, with either a 2048 bit or greater RSA key or a 256 bits or greater Elliptic-Curve (ECC) key.
  • Invalid certificates result in a hard failure and no connection.

If your app’s network communication is not ATS compliant, you can define security exceptions in the meantime. Keep in mind this affects both direct and indirect (third-party) network communications within your app. There are two approaches to defining security exceptions via your app’s Info.plist.

  • The first approach is to disable the ATS feature completely.
  • The second approach is to explicitly define exceptions for each domain. This can be tricky since you must know all direct and indirect HTTPS calls made by your app and failing to include a given domain will result in network connection failures.

Please refer to the iOS 9 documentation for more information.


06 May

Android Platforms Adoption (May 2015)

Every year I like to take a snapshot of Android platforms adoption for historical purposes. Below is the Android platform comparison 2015 vs. 2014. (Search my blog for previous ones).

Keeping track of platform adoption is important as it directly impacts what developers should be focusing on vs. what should be deprecating or end-of-life.

(Data source: Android Developer Dashboard)



Since 2014 we have Lollipop with its two API levels (21 and 22) with an overall 9.7% adoption rate. Ice Cream Sandwich went from 14.3% down to 5.3%. Jelly Bean decreased from 61.4% down to 39.2%, and KitKat jumped from 5.3% up to 39.8%.

Related to this see On Android and Fragmentation (early 2014).


18 Apr

Android and Microsoft (2015)

(Image Source: Mario Tomás Serrafero)

I find this interesting: the recent move by MSFT to get into and “steal” the Android space.

Today, thanks to new leadership at MSFT (Nadella), it seems the company is entering a new phase — with new vision and no-or less ego than before.

And with this, MSFT is directly taking advantage of open source software to go after the Android market.

By leveraging the Android open source baseline from Google and investing around $70M in Cyanogen, it is going after the Android-based hardware (think Emerging/Global markets) independently of or not having to worry much about the underlying hardware/devices, while at the same time not depending or having to use Google Services and instead MSFT has the opportunity to introduce their own services and apps on Android-based hardware. A game changing strategy.

Very interesting indeed…

Thanks to Google for the Android Open Source Project which makes all of this possible. Google knew the risks and benefits, so did Sun Microsystems when it open sourced most of Java, and of course, let’s not forget the Linux core OS which triggered the OSS revolution and ecosystem. Open Source Software (OSS) is a beautiful thing…

Side note: It was around 2011 when MSFT made the initial deal with Nokia and many, including I, found it strange that Nokia would go the MSFT route — true signs of trouble within Nokia back then. Many of us asked ourselves why not go the Android way instead. But I believe ego and lack of vision (Elop/Ballmer) played a large role in the decision. MSFT ended-up acquiring Nokia as expected. Today, their combined market reach is tiny as expected, as compared to Apple and Google.


18 Feb

Improving The Patient Experience (early 2015)

Disclaimer: The French Hospital Medical Center app is powered by Phunware’s Vertical Solutions platform, one of the products that I manage at Phunware.

As the mobile lifestyle, advanced smartphones and advanced networks continue its path to convergence powering the pervasive, actionable Mobile Context, we are starting to see its impact on people’s daily lives. One such example is the impact and benefits that this brings on the user experience and the Healthcare space.

Improving the Patient Experience

Recently, the French Hospital Medical Center launched its first mobile app.

The FrenchWay
(Click link to see video via KSBY News)

“From the time that you leave your house, you’ll get a reminder and it’ll take you actually into the hospital door to the actual department you’re going to, and then after your appointment, you can continue to navigate to the pharmacy, so this really helps people have a lot less stress as they’re going through the entire healthcare journey… It’s also great for visitors as well because sometimes you may have a loved one in the hospital and trying to find them can be pretty stressful.”

This is a prime example of how the young and the old can leverage their mobile devices with its advanced features and sensors, and access to fast networks, to improve the patient experience. The key is to bring the right information at the right time, from hospital and doctor information, to information about related places, using dynamic content and notifications and location-based services such as mapping, wayfinding and navigation. Location marketing with geofences and Beacons for outdoor and/to indoor navigation and outdoor and proximity notifications brings enable for very interesting use cases and are of particular interest to Hospitals (and other verticals), as it helps patients deliver information in real-time as well as helping patients reach their destinations, all via their smartphones, improving the patient experience with the added benefit of helping reduce the costs associated with deploying such a solution as well as costs related to late or missed appointments.

Related see Dignity Health Mobile App Helps Patients Navigate Hospitals.


05 Aug

Three Generations of Mobile Apps (Aug 2014)

We currently are at the third generation of native Mobile apps (2014), with each generation building upon the previous one.

The first generation was introduced to the “masses” circa 2000. This generation of mobile apps were Operator-centric and built for the first generation of mobile handheld devices such as PalmOS, J2ME, WinCE, BlackBerry OS, Nokia devices, Psion and other.

The second generation came with the iPhone and Android (2007–2008), essentially giving (re)birth to a new generation of mobile apps where rich content was king. These were apps based on advanced Smartphones and higher-speed networks that pretty much made the previous generation obsolete. During this time period the Ecosystem took center stage away from the Operator. Many of the companies behind the first generation such as Nokia, BlackBerry and Microsoft were impacted during this time period in major ways — some are gone while others and are still trying to recover.

More recently, we have entered the third generation of mobile apps where the user and user context is king, with sensors on the device and core services and infrastructure residing on the cloud.

The following table summarizes the three generations of mobile apps (2014).

mobile app generations


23 Dec

On Location (and Other Sensitive) Data

Installing apps, Android in this case, is at times a bit of WTF. It shouldn’t have to, but it is. The amount of personal information that some apps gather can be extreme. This concern is especially true after Google removed the very necessary App Ops (permission manager) app.

Let me provide an example. An app that I recently installed asked for the following (and other) permissions:

Your location
precise location (GPS and network-based)

Your personal information
read your own contact card

Phone calls
read phone status and identity

Your social information
read your contacts

Your accounts
find accounts on the device

Not all apps need such amount of personal information. It is so important to gather just the information that is really needed, and nothing else. It is also very important to be responsible with things such as geo-fencing as well as having in place good privacy guidelines that are really in taken seriously.

A number of years ago I wrote a set of Guidelines for Location (and Other Sensitive) Data that that are still quite relevant. Check them out; I hope you find them useful.


15 Dec

BlackBerry’s Little Gem

Has BlackBerry hit rock bottom? Look at the following chart for BlackBerry’s stock price and value.


BlackBerry’s stock right now is around $6.06, which is up from $5.89 (all time low?).

It is crazy. BlackBerry has millions of users, with a strong history in the global Enterprise/IT market, with secure software and infrastructure, and communication-and other kinds of apps for Mobile. For years, BlackBerry have had a little gem that not many people talk about. If you have been in Mobile for a while, you will remember a company called Certicom and their IP around Elliptic Curve Cryptography (ECC), which was acquired by BlackBerry around 2009 or so, and that (for better or worst) even the NSA uses and recommends.

ECC is a very strong encryption algorithm with great characteristics, especially when it comes to Mobile, which is even more important after the rumors around RSA-encryption and NSA backdoors. Some of ECC’s advantages include: (1) Shorter keys are as strong as long key for RSA, (2) Lower on CPU consumption, and (3) Lower memory usage, when compared to other algorithms.

BlackBerry should be maximizing/monetizing ECC in major ways. The following is from The Case for Elliptic Curve Cryptography (NSA):

Despite the many advantages of elliptic curves and despite the adoption of elliptic curves by many users, many vendors and academics view the intellectual property environment surrounding elliptic curves as a major roadblock to their implementation and use. Various aspects of elliptic curve cryptography have been patented by a variety of people and companies around the world. Notably the Canadian company, Certicom Inc. holds over 130 patents related to elliptic curves and public key cryptography in general.

BlackBerry should turn the above into an opportunity.

I think having Mr. Chen run the BlackBerry is a good thing — I’ve the feeling he will do better than any of the previous CEOs; there is hope for BlackBerry. He should focus on their core assets and skills: from Enterprise to mobile, mobile device management (MDM), and security (ECC). One thought is to exit the hardware space and focus on Software — as Mr. Andreessen well said: “software is easting the world”.


Related to this:

* BlackBerry: Not dead yet! Seriously

* BlackBerry’s Potential Biggest Patent Asset: Elliptic Curve Cryptography

13 Dec

shift 2020 – How Technology Will Impact Our Future

Check out Rudy De Waele’s new book project titled shift 2020 – How Technology Will Impact Our Future — a collaborative book including foresights on how technology will impact our future by some of the world’s leading experts.

See the related Kickstarter project.

The story

The idea of shift 2020 is based upon Mobile Trends 2020, a collaborative project I launched early 2010. It’s one of the highest viewed decks on Slideshare (in the Top 50 of All Time in Technology / +320k views). Reviewing the document a couple of weeks ago, I realised the future is catching up on us much faster than many of the predictions that were made. I thought it was time to ask the original contributors for an update on their original predictions and new foresights for the year 2020.

And here is Rudy!

(love that guy!)

I am honored to be one of the contributors to both Mobile Trends 2020 and the new shift 2020 project.

Visit the related Kickstarter project.

Final contributors include:

  • Neelie Kroes (VP of the European Commission)
  • Douglas Rushkoff
  • Salim Ismael (Singularity University)
  • Loic Le Meur (LeWeb)
  • Shannon Spanhake (Innovation Officer San Francisco)
  • Adeo Ressi (The Founder Institute)
  • Saul Klein (Index Ventures)
  • Aubrey de Grey
  • Sunny Bates (Kickstarter / Jawbone)
  • Carlos Domingo (Telefonica Digital)
  • David Rowan (Wired Magazine)
  • Laurent Haug (Lift)
  • Martin Recke (next)
  • Will Page (Spotify)
  • Scott Jenson (Google)
  • Gerd Leonhard (The Futures Agency)
  • Yuri Van Geest
  • Russell Buckley
  • Russ McGuire (Sprint)
  • Kwame Ferreira (Kwamecorp)
  • Delia Dumitrescu (Trendwatching.com)
  • Georgie Benardete (Shopbeam)
  • Hans-Holger Albrecht (CEO Millicom)
  • Tariq Krim (JoliCloud)
  • Dr. James Canton
  • Andrew Hessel (Autodesk)
  • Christian Lindholm (Korulab)
  • Eze Vidra (Google Campus)
  • Harald Neidhardt (MLOVE)
  • Raina Kumra (Juggernaut)
  • Robin Wauters (Tech.eu)
  • Nicolas Nova
  • Gianfranco Chicco
  • Shaherose Charania (Women 2.0)
  • Ken Banks
  • Marc Davis (Microsoft)
  • Felix Petersen
  • Kelly Goto
  • Erik Hersman (Savannah Fund)
  • Tom Coates
  • David Risher (Worldreader)
  • Glen Hiemstra (Futurist.com)
  • Jessica Colaço (iHub)
  • Mark Kanji (Apptivation)
  • Rohit Talwar (Fast Future)
  • Priya Prakash (Changify)
  • Andrew Berglund (Geometry Global)
  • Alan Moore
  • Martin Duval (Bluenove)
  • Maarten Lens-FitzGerald (Layar)
  • Andrew Bud (mBlox/MEF)
  • Andy Abramson
  • Fabien Girardin
  • C. Enrique Ortiz
  • Raj Singh (Tempo AI)
  • Inma Martinez
  • Robert Rice
  • Ajit Jaokar
  • Jonathan MacDonald
  • Tony Fish
  • Dan Appelquist
  • Redg Snodgrass (Stained Glass Labs)
  • David Wood
  • Mark A.M. Kramer (razorfish Healthware)
  • John Kieti (m:lab)
  • Aape Pohjavirta
  • Kosta Peric (Innotribe)
  • Blaise Aguera y Arcas (Microsoft)
  • Michael Breidenbruecker (Reality Jockey)
  • Tricia Wang
  • Louisa Heinrich (Superhuman)
  • Mike North (UC Berkeley)
  • Mac-Jordan D. Degadjor
  • Kate Darling
  • Simon White
  • Chris Luomanen (Thing Tank)
  • Ariane Van De Ven (Telefonica)
  • Ed Maklouf (Siine)
  • and others…


12 Nov

Enabling Voice Communication on Android Apps

Check out the new guest post that I wrote on Enabling Voice Communication on Android Apps, for the Safari Books Online blog. It covers how to enable voice communication using the Android SIP Stack/API.

Enabling voice communication on Android apps is possible via the Session Initiation Protocol (SIP) stack. This protocol originated in 2000 as a signaling protocol in support of Voice over IP (VoIP). With today’s move to IP wireless networks such as LTE, SIP is the core signaling protocol for voice over IP Multimedia Subsystems (IMS). In this post we will explore how to enable voice communication on Android apps by using the Android Session Initiation Protocol (SIP) stack. With the transformation of traditional networks as IP-networks, and the future of voice as a “data app,” expect media-rich and location-aware communication apps, where the smartphone plays a central role in personal communications. This means that developers can now create a new breed of voice communication apps like never before. This post assumes you are somewhat familiar with the Android platform and the Java language.

Read Enabling Voice Communication on Android Apps (source: Safari Books Online).


13 Sep

Betting on Nokia (2013)

(Image source: http://blogs.telegraph.co.uk)

Have you given up on Nokia?

From my perspective, due to its recent (couple of years old) debacles and endeavors with MSFT, I had stayed away from Nokia.

I never believed on how their MSFT strategy was approached.

Nokia should have totally maximized their Smartphone hardware design expertise, and should have offered that to the world — running Android, Windows and their own Advanced OS. If they have done that, by just supporting the Android OS, they would have owned the other side of the marketshare (not already owned by Apple).

But instead they handed this unique opportunity, and without contest, to Samsung. Today Nokia has lost such hardware design expertise to Microsoft.

And while the world was changing, Nokia management was too comfortable. Call it arrogance or not, they assumed their leadership and marketshare would last, versus seeing it erode at such a fast rate.

Nokia failed to adopt-standardize on “touch interactions” fast enough — even though they had the technology, OS based on Symbian and R&D brain-power. Then they pulled out from Japan, then pulled out from the USA, gave up on MeeGo Phone, and sold bulk of its Qt business to Digia. Its audience, platforms, content and ecosystem was all too much, too complex, affecting company focus.

And all the above happened during the time when the Smartphone itself, the mobile ecosystem and the mobile-lifestyle in general were being redefined, by Software, by advanced interactions and beautiful interfaces, rich content, faster networks, and awesome user experiences, all which when put together led to the awesome transformation of the Mobile space as we see know it today. This is a period of 3-5 years, really the culmination of 15 years of evolution that started with pagers, feature phones, Smartphones, and now Advanced Smartphones.

Those were the early days of Mobile, which also were the days of Research in Motion (now BlackBerry) and Nokia. Because BlackBerry and Nokia where both early pioneers, is the reason why their IP portfolios today are worth billions of dollars; Nokia’s alone is worth more than $6 billion dollars. Blackberry’s IP portfolio must be very valuable as well.

There were other factors that contributed to Nokia’s demise on Mobile.

Nokia was too dependent on the Network Operators/carriers. This is to the point of sacrificing/delaying the introductions of advanced (more costly) devices into the consumer market.

Control then moved away from the network operator and into the Ecosystem — led by Apple and Google.

Back then, Nokia saw BlackBerry as a threat. They saw Apple as a thread as well, but Nokia didn’t see Android as much of a threat.

And the final straw was Nokia giving-up what is the MOST important aspect of Smartphones — the Software. And because Nokia’s software strategy was MSFT alone, it was game was over.

But past is past. Nokia has finally cut clean from MSFT, and got rid of legacy stuff. Yes, it lost lots of good people, but life goes on. The market benefits from this via new startups formed by ex-Nokians.

Nokia can now start from scratch. In many ways, it is a blessing.

So am I betting on Nokia?

Yes, I am.

Nokia is a company with lots of passion and pride. It has the smarts/people. It currently has the technologies and products that can be monetized (network, maps, etc). It owns tons of mobile and wireless intellectual property that is worth billions of dollars. And now that MSFT is buying Nokia’s device business, and is cutting clean from MSFT, Nokia is in the position to reinvent and simplify itself.

I even see how Nokia would re-enter the mobile space. If you think about it, mobile is still young; what I mean is that while the “mobile use case” has been proven, the technologies are still evolving. Yet to be invented are new approaches and use-cases related to the Mobile Lifestyle.

So I bought NOK stock and it has been going up.

(Disclaimer: I am not giving you financial advice here, just a personal perspective).


27 Apr

Facebook buys Parse :-/

Interesting — Facebook Buys Parse To Offer Mobile Development Tools As Its First Paid B2B Service (via TC).

First congrats to Parse, for the monetization event.

I have been a Parse.com fan for a while and even wrote a few months ago an article on using Parse on Android that was published at IBM DeveloperWorks.

Indeed, the Parse API is pretty cool — a very well thought out/organized API with platform/OS-specific bindings, and a very cool “cloud code”.

One of the things I liked about Parse was its independence from the “rest”. But this independence is now gone.

From the developer’s perspective, I have mix feelings about this acquisition — the only apps I want to run against or have dependencies to the Facebook back-end are Facebook apps, and nothing else. As a consequence, my use of Parse will not be limited mainly to such.

There is an alternative to Parse: Apigee, another back-end as a service/cloud API company I am a fan of. They have an API similar to Parse; not as sophisticated, but I believe it will get there. Apigee was a speaker at Android Dev Austin a few months back and I can see how Apigee will continue to evolve. As a matter of fact, this acquisition of Parse by Facebook is probably a good thing for Apigee. (Note to self: write an article on Apigee’s APIs).


17 Dec

Dell to exit global smartphone business



Today I read “Dell to exit global smartphone business” (Austin Business Journal).

From the ABJ article:

“It needs a lot of investments to really be successful,” Clarke told Forbes.

Translation: “…we don’t know how to make it happen”.

I say this because Dell has invested, a lot — but have not done it right. Dell already have the tech and ops resources to make this happen, but it keeps failing on the Go-to-Market (business-side) of the equation; in other words the problem is not the tech side but the business side.

A very sad part of this story is that many people didn’t know Dell had a smartphone business, less a global one!

What Dell should do?

  1. Find the right people, especially business people that understand Mobile,
  2. Quit the politics that again and again have prevented Dell from successfully going to market,
  3. Invest on true innovation, and,
  4. Really invest on Mobile and mobile people.

From the ABJ article:

The Round Rock-based company pulled the plug on selling its mobile devices in the United States earlier this year.


Perhaps it is the right call, for Dell to just focus on server, cloud and services.

Will Dell quit the Tablet market as well?

The future of Personal Computing is Mobile!


21 Nov

Article: Parse cloud-based services for Android apps

My latest article on Mobile & Cloud computing…

Summary: Explore the advantages of storing mobile application data in a private cloud with this introduction to the Parse SDK for Android. Mobilist C. Enrique Ortiz introduces the Parse API classes for cloud-storing and manipulating users, data objects, and files for your mobile applications.

See Parse cloud-based services for Android apps (IBM developerWorks).

01 Oct

Total Time Spend Using Mobile Web vs. Apps (October 2012)

Saw this today at BI website…

Source: Business Intelligence (BI)

Source: Apps More And More Important Than The Mobile Web (Business Intelligence). Original report by Nielsen.

The above is self-explanatory…

What I find ‘funny’ is that over time I have noticed that Business Intelligence’s opinion on “native vs. web on mobile” swings back-and-forth (based on the top news of the day). In this particular case, all the recent attention to “native vs. mobile web” is thanks to Mr. Zuckerberg.


30 Sep

The Eternal Debate — MoMo London Event on HTML5 v.s. Native (Sept 2012)

Native vs. Web
Image Source: Mobile App Testing Blog

Seems that I missed a very good debate. I just read a blog on MoMo London event on HTML5 v.s. Native.

Seems like an eternal debate.

Today in 2012, I am still amazed we still are debating this and have not been able to address this. This is really a ~10 year old debate, still driven by the exact same issues and pros/cons as before — centralized vs. not, cross-platform vs. not, maintainability and fragmentation, code-reusability or not, better user experience vs. not, performance, security, access to device APIs vs. not, thin vs. thick, app discovery, etc. etc. etc.

We can argue the basics are here (HTML5, CSS3 and JS-and-related frameworks), but creating great mobile webapps with great user experiences is today only possible by a few; in other words, is a niche area. (Not even Facebook was able to pull it off, right?).

The day the “common mobile developer” is able to create great mobile webapps with ease, is the day this debate will end.

Today still, “user experience” (driven by network latency, app richness, toolsets, adoption by big brands) is best maximized on mobile native. Today still we have to talk about classes of mobile applications (again driven by network, richness, performance, storage, toolsets, maintainability, security, cost of one vs. other, etc) — then decide what is better suited — native vs. web on mobile.

How much longer will it take settle out this debate? 3 years? 5 years? 10 years? Right now I say around five years — I wish I am wrong. But does it really matter?

In the meantime, successful mobile developers redefine the meaning of “full stack developers”; successful mobile developers must be “End-to-end, Cross-platform, Full Stack Developers” — this is a lot of complex ground to cover.

Related to this see “The biggest mistake we made as a company was not investing enough on native.” — Zuckerberg (2012).


11 Sep

“The biggest mistake we made as a company was not investing enough on native.” — Zuckerberg (2012)

The title of this blog is not what Zuckerberg actually said, but is what he really meant.

From TechCrunch Disrupt — Zuckerberg Shows He’s The Right Man For The Job:

“The biggest mistake we made as a company was betting too much on HTML5.” While building native apps that were bacially just a wrapper for the mobile web standard let it experiment quickly, it made the apps run way too slow. “We burnt two years.”

This validates what I have been saying for years… Don’t take me wrong, I’m a fan, user and developer of webapps. Web on mobile is big and the mobile browsers and frameworks are getting so advanced, and the mobile webapps so kickass, but for certain kinds of apps, especially rich consumer-based applications, native is the way to go today.

Consumers are about great user experiences and great quality. The “mistake” Zuckerberg refers to is not really that they bet “too much” on HTML5, but that they didn’t invest enough on native.

But that said, FB has nailed it down; recognizing the need to invest on the native apps and related infrastructure, and focusing on mobile first.

Any company going global must have a mobile first strategy — we know that for many around the world, their online experience will be on mobile.


23 Jul

Starbucks App == Mobile + Convenience

The Starbucks App for Android 2.0 is out on Google Play (see announcement on VentureBeat).

Good to see…

(I was one of the people who contributed design & dev to this product, specifically the Card Management tab/functionality, plus some other.)

Starbucks have proven, starting with their iOS app, that consumers are ready for mobile payments — as of April 2012, Starbucks apps have done over 42M mobile payment transactions (see announcement on VentureBeat).


Convenience is always a big winner. In the case of Starbucks it is about payments, rewards and store information right on the palm of your hands.

There is another important aspect here. It also shows that stores must have the whole infrastructure in place to be successful:

  1. The POS that are enabled with the appropriate readers and software,
  2. The devices/smartphones with the SW and functions (the apps), and,
  3. The scalable service infrastructure with the appropriate back-end integrations, and the right kind of services-and content — in the case of Starbucks, authentication, payments, rewards, store information and related-integrations.

It is then that users will adopt this in masses; and, yes, it is about convenience.

(Card management tab with Pay Now, and embedded PayPal Integration for Card Reload)

Digital cards are at the center of the app. The app, which is global-ready, allows smartphone-users to load the digital cards (dollars, pounds, etc, depending on country) via credit cards and/or PayPal — all within the app, thus maximizing the user experience. The digital cards are then scanned at the stores. For this, the app uses 2D-barcodes that are scanned/read by the POS using regular barcode scanners, consummating the transaction.

Looking forward, this app is a good candidate for NFC and/or other proximity-based technologies. If the NFC infrastructure was in place, that is, the readers and the NFC-capable smartphones, I will bet that it would also be a winner. But full, pervasive NFC deployments are still are a few years away, delaying its adoption. As a result, today, 2D-barcodes is the way to go.

(This is not real, just a concept scenario that I put together for the Starbucks app with NFC support)

As mobile app designers, the important thing is to design your application in a way that 2D-barcodes or NFC or other are just interaction channels — the key is keeping the rest of the app- and related supporting infrastructure (servers, authentication, exposed services, payment infrastructure and so on) properly abstracted. As a side note, this is a reason why Square is ready for the future — it has all the infrastructure in place, and today their reader is the Square-reader, and tomorrow it can be something else. Starbucks is ready too.


16 Jul

Security & Privacy on Mobile Apps, Part 3 – PCI Compliance

This is Part 3 of a series on Security & Privacy for Mobile Apps.

Part 1 of this series introduced main concepts related to security on mobile apps. Part 2 went deeper into the security elements and guidelines related to security and privacy on mobile applications. In this Part 3, I will cover security from the PCI compliance perspective.

Handling Personal or Sensitive Information

Personal and sensitive information include any information that is critical for a user, for example credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Any such information must be properly handled and secured.

When dealing with credit cards in particular, you may have to adhere to strict security requirements such as the ones as defined by the Payment Card Industry Security Standards Council, or PCI for short. The PCI council defined a number of requirements and certification to help to ensure both devices and software applications all take the proper steps to protect cardholder data. The PCI council consists of the following companies: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.

Even if your application is not handling cardholder information, the requirements by the PCI council are good guidelines to follow if your mobile (web) application deals with personal sensitive information of any kind.

PCI Data Security Standard (DSS) requirements

Let’s take a look at the PCI Data Security Standard (DSS) requirements. These requirements apply to “any entity that stores, processes, and/or transmits cardholder data.” In short, “if your business accepts or processes payment cards, it must comply with the PCI DSS.” Note that “to comply”, means that the payment application must pass a PCI-provided assessment.

Table 1: Payment Application DSS Requirement

   Source: Payment Card Industry Security Standards

The PCI Data Security Standard defines fourteen (14) requirements — some technical while other operational — that affect both the server-side and client/mobile-side of the payment application. Let’s cover each of these requirements in some more detail:

1. Do not retain full magnetic stripe, card validation code or value or PIN block data

How to: Always prompt for such information; never store locally on the device. Always prompt for PIN.

2. Provide secure password features

How to: Always prompt for PIN before allowing access to the app’s critical paths or sensitive information. Use the PIN to secure application data.

3. Protect stored cardholder data

How to: Do not store cardholder information on the device. Tokenize access to critical information (tokens are covered below). Use the PIN to secure application data.

4. Log application activity

How to: Keep a local log of critical activities, such as when user logs into the application, performs a purchase, and so on. This typically is a circular log. Provide the means to remotely access or upload the log as needed.

5. Develop secure applications

How to: Design and implement the mobile application with security in mind. Do this by implementing the different requirements being discussed in this article.

6. Protect wireless transmissions

How to: Perform all communication over an encrypted secure connection (typically over HTTPS/TLS).

7. Test applications to address vulnerabilities

How to: Implement a robust test-suite that includes automated and manual testing that validates that no access to critical application paths is possible unless the user authorizes it via a PIN, that API calls and data over network connections is in fact being encrypted, that no credit card information is stored locally, and that any personal information stored in local data is properly encrypted.

8. Facilitate secure network implementation

How to: See #6 above

9. Do not store cardholder data on a server connected to the Internet

How to: Design a network architecture that separates production systems from the public Internet. Deploy production servers with critical/personal information behind a firewall.

10. Facilitate secure remote software updates

How to: Only trust software updates from trusted sources. Leverage app stores/markets and app signing for native applications. Leverage centralized approach of mobile web apps. Perform all software updates over a secure network connection.

11. Facilitate secure remote access to application

How to: See #10. In addition, see #6 — all remote/network communication shall only be done over secure network connections.

12. Encrypt sensitive traffic over public networks

How to: See #6 above

13. Encrypt all non-console administrative access

How to: See #4 and #6 and #10. All access to secure data, administrative or not, shall be done over secure connections.

14. Maintain instructional docs and training programs for customers, resellers and integrators

How to: From the mobile application perspective, provide FAQ and Help pages that describe the privacy and security aspects of the application. Include Privacy terms and conditions.

Other PCI Information and/or Requirements

The following two tables show the general PCI goals vs. requirements, and PIN-entry device security requirements.

Table 2: PCI Data Security Standard (DSS) requirements

   Source: Payment Card Industry Security Standards

Note that most of these requirements on Table 2 were covered on the previous section.

Table 3: PCI PIN Entry Device Security Requirements

   Source: Payment Card Industry Security Standards

And these requirements on Table 3 are related to physical devices, in particular device characteristics and management requirements.


On this 3-part series we have covered security on mobile applications – introduction, elements and guidelines for secure mobile apps, and PCI requirements for mobile payment applications. At the end, it is about protecting the user by protecting related critical information –credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII); all such information must be properly handled and secured.

As privacy continues to become more critical over time, with the number of apps exponentially increasing, and with potential legislation in the future, having clear privacy and security implementation, wording/messaging and responsibilities are all very important.

Finally, as product owners and developers, we are all responsible for properly implementing our mobile applications and protecting the user…


12 Jul

On Mobile Industry Numbers and Mobile Jobs

The other day I tweeted this:

(URL: https://twitter.com/eortiz/status/223096404233564160)

Then I read at the Royal Pingdom blog some interesting Internet 2011 in numbers; looking at the mobile-related numbers, we have:

Mobile (July 2012)

  • 1.2 billion – The number of active mobile broadband subscriptions worldwide in 2011.
  • 5.9 billion – The estimated number of mobile subscriptions worldwide in 2011.
  • 85% – Percentage of handsets shipped globally in 2011 that included a web browser.
  • 88% – Apple iPad’s share of global tablet web traffic in December.

    So the mobile space is a pretty hot space indeed. Let’s now look at some mobile-related job salary numbers, courtesy of Indeed Salary; note these are *average* salaries:

    Mobile Architect

    Mobile Developers

    Mobile Designer

    Mobile Web Developer

    Android Developer

    iOS Developer

    Windows Mobile Developer

    BlackBerry Developer

    Symbian OS Developer

    Mobile Product Manager

    I actually find this quite low for Mobile Product Managers.

    Mobile Project Manager

    Let’s now look at some trends, courtesy of Indeed Trends. Interesting is how it starts to trend up towards the end of 2010 for all the top mobile OS platforms –iOS, Android, HTML5:

    iOS Job Trends

    HTML5 Job Trends

    Android Job Trends

    Mobile-app Job Trends

    Symbian OS Job Trends

    Note the roller-coaster trend for Symbian OS…

    Windows Mobile Job Trends


    BlackBerry Job Trends


    So in conclusion, the mobile space is red HOT… The demand is there. It definitely is a good time to be a mobile technologist, developer, product manager, and so on… globally!


    09 Jul

    Security & Privacy on Mobile Apps, Part 2 – Typical Security Elements of a Mobile Application

    This is Part 2 of a series on Security & Privacy for Mobile Apps.

    In this Part 2 of the series, we will cover the elements of mobile apps, and some guidelines related to security and privacy.

    (Note: in this article mobile apps means both native and webapps)

    Personal and sensitive information include any critical information such as credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Such class of information must be properly handled and secured.

    Recall from Part 1 the main classes of “privacy functions” performed by mobile applications:

    • Class A — Collects data
    • Class B — Stores data
    • Class C — Shares data
    • Class D — Tracks the user

    Each of the above functions may have an impact on your mobile application design and implementation, as well on how you should craft your privacy policy document/content. It is not only about collecting or not sensitive information, but it is also about:

    1. Only collect, store, share, track if really needed; vs. collecting information “just in case for potential future use”, and,
    2. Preventing others from gaining access to the sensitive data collected by your app (that is, protecting the information), and,
    3. Communicating to the user what the app does with respect to sensitive data (via private policy page).

    Let’s go a step deeper in understanding how the security and privacy functions listed above may affect your mobile application; to better visualize this let’s look at the following diagram which illustrates the typical elements of a mobile application with annotations on security and privacy:

    Diagram Source: http://CEnriqueOrtiz.com. Click to enlarge.

    In this diagram we can see the user interface, access to local storage, network transmissions/access to remote information and/or APIs, sharing, and other — most if not all parts of the mobile app have security and privacy considerations:

    1. The Device/Smartphone/Tablet

    • Your application — your app, native or webapp.

    2. Graphical User interface with its screens, widgets, navigation, web-views, etc.

    • Always have a Privacy Policy page; typically web (view)-based allowing you to simplify related maintenance/updates by centralizing the location of privacy text itself
    • Protect access to critical app paths/screens with a PIN — prompt the user for PIN

    3. Local store

    • This can be a local DB, the filesystem, configuration files, preferences
    • All sensitive data in local store must be encrypted, using a unique secret key
    • For key generation use the PIN from the user + a device unique ID; calculate the hash, store the hash – do not store the PIN. Recalculate the hash dynamically for comparison/key-validation
    • Examples of sensitive data: payment-information, cardholder information, related 2D barcode images
    • Store critical files on the app’s storage area (vs. public storage) so that such information is automatically removed when the application is uninstalled
    • If utilizing an encrypted database, be aware of potential performance issues — encrypting/decrypting data are expensive operations!

    4. The Network / Data transmissions

    • Most apps are connected to the cloud — to invoke a service on the web, to push analytics data, other
    • All data over the network shall be encrypted — use HTTPS/TLS, VPN
    • Depending on your app requirements, you many have to encrypt your messages using additional encryption + keys
    • Consider tokenization — critical information shall be tokenized; don’t use information such as Social Security numbers, drivers licenses directly; tokenize such
    • All data between the device and the server shall be encrypted as previously described

    5. Context Information – this is information like time, geo/location, sensor/ambient data, preferences, social, other

    • The user shall be notified if ambient, social or profile information is utilized by the application
    • This is done (a) via application permissions, and (2) via Privacy Policy page/screen

    6. External services/servers — Analytics, Facebook, Twitter, etc

    • The problem is that often “how and when” related data is “collected and shared” is totally out your apps’ control
    • Make sure you protect yourself — the user shall be notified about things like analytics-data being collected/utilized by the app.
    • This is done (a) via application permissions, and (2) via Privacy Policy page/screen

    7. The Activity Log is used to record key activity information that can be used for debugging or support purposes, and that may or not be accessible remotely.

    • Encrypt the activity log on local store
    • Encrypt activity log when/if transmitted

    8. Your App Servers on the Cloud

    • Designing a secure network architecture is important
    • (a) Use DMZ for publicly visible servers
    • (b, c) Servers with sensitive data shall resides behind a firewall
    • (d) All server DBs shall be properly protected and encrypted if possible

    And very important is to keep good separation between the mobile app and the server-side; and to push complexity as much as possible to the server, with the goal of localizing all critical information, related-functions and validation to the server-side of things. Remember, while you personally may not get audited for security and privacy considerations, the company you are developing the app for might be; so minimize complexity by pushing as much responsibility as possible to the server.

    Tokenization & Encryption

    Tokenization and encryption were mentioned a couple of times on the annotations/guidelines above; let’s expand a bit on this. Tokenization & Encryption are two ways of protecting sensitive data.

    Tokens are abstractions used to hide real data. Tokens are used as substitutes to Personally Identifiable Information such as SSNs. A simple example of a Token is a customer id (vs. using SSN):

    • Avoid storing personal identification; instead use the Tokens to access critical information,
    • Because the actual critical information doesn’t have to reside locally, the location of the critical information can be centralized, helping minimize sources of leakage.
    • But this comes with a price: Tokens must then be created, mapped/substituted, and managed.

    And of course, Encryption is a very important way of protecting sensitive information. Always encrypt data that must be stored and/or transmitted. Encryption also comes with a price:

    • You may need to identify and implement the encryption functionality explicitly,
    • You may have to select specific algorithms (such as AES) and key-sizes (such as 1024) depending on your business needs,
    • You have to deal with key management — key generation (for example, based on PIN and device unique ID), storage, and other related key-management,
    • There are performance implications.

    Encryption and tokenization are not mutually exclusive and you should consider using both techniques on your mobile application. 

    To conclude this article, I am including some related guidelines that I originally wrote back in 2004; still very applicable today.

    Summary General Guidelines for Mobile Applications with Sensitive Data

    Always Alert the User

    • Show a privacy policy notice – The user must be notified that the application collects, records and transmits personal (location) information.
    • This privacy notice must be properly localized (i.e. right language for the particular country) and must be explicit.
    • This privacy notice must be displayed and acknowledged, at least once (probably the first time the application is used). This acknowledgement must be recorded. Note that recording the acknowledgement also serves to protect you, validating you did your part notifying the user.
    • This privacy notice should be re-displayed every once in a while, lets say once a month, or once a quarter, or something that is configurable, but the notice should never be disabled.

    The End-User, the Ultimate Decision Maker

    • The application must provide the means to turn off location tracking at ANY time. Always give the device-user the ultimate decision for being tracked or not, for using geo-location information or not!

    Safeguard All Captured Information

    • Location information and ALL personal information, if stored on the device, must be safeguarded: 1) not accessible by other programs or entities, 2) and possibly encrypted.
    • Location information and all personal information, if transmitted, must be properly encrypted.
    • And if stored on the server, must be totally safeguarded (access-control, encrypted).

    Use the User Context responsibly

    • The mobile context can provides awesome information to your application; for example, you can use location information for location-based reminders.
    • Geofencing, the ability to track using GPS or Wi-Fi (or other means) when a person crosses a pre-defined boundary or area, can be a scary thing if used for tracking others. Don’t use geofencing to track others.
    • Always ask for permission.


    Mobile applications may Collects, Store, Share sensitive data, or even track the user’s location. Each of these functions may have an impact on your mobile application design and implementation, as well on how you should craft your privacy policy document/content. In this article we covered the different elements of a secure mobile application with guidelines that you should take into consideration when designing/implementing your mobile app.

    Stay tuned for Part 3 of this series which covers the Payment Card Industry Security Standards and related-guidelines.



    01 Jul

    Security & Privacy on Mobile Apps, Part 1 – Introduction

    This is Part 1 of a series on Security & Privacy for Mobile Apps.

    (Note: in this article mobile apps means both native and webapps)

    Are you Serious About Security on your mobile apps or webapps?

    Security and privacy is an area that too often is not being properly addressed on mobile apps in general. From the product requirements, to the design and implementation of the mobile app, properly securing sensitive information means addressing this end-to-end: on the device/smartphone, through the network, and on the servers on the cloud.

    Examples of sensitive information:

    • Personal Identifiable Information (PII)
    • Cardholder and other credit card information
    • Health/medical information
    • Tracking users/geo-location

    And it is not only about collecting or not sensitive information, but also about 1) preventing others from gaining access to the sensitive data collected by your app, and 2) how to communicate to the user about how the app itself deals with such sensitive data.

    As product owners and developers, we all should follow proper security and privacy guidelines, regardless of the kind of application. But when dealing with critical or sensitive information, we must go beyond guidelines and treat privacy and security as application requirements.

    Increase in Apps with privacy & security requirements

    Developers do need to be serious about security and privacy on their mobile apps:

    But many developers find addressing privacy/security as challenging:

    Why the need to be explicit about security and privacy?

    Addressing security/privacy goes beyond protecting and securing data. It is a fact that security/privacy on mobile apps can quickly become confusing. And this impacts how we tell the users about what the application does with sensitive data. Typically this communication is done via privacy terms and/or policies that are hundreds of lines long and hard to read on a mobile device, thus many people simply skip reading it.

    Simplifying privacy communication — a case for “Classifying Apps”?

    Imagine that we can abstract and simplify how we communicate to the users the matters related to privacy/security. And idea is on classifying the Apps based on how they handle sensitive data, for example:

    • Class A — Collects data
    • Class B — Stores data
    • Class C — Shares data
    • Class D — Tracks the user
    • Any other?

    Regardless, think about these classes when designing your application, and crafting your privacy policy documents.

    Now imagine that these classifications are standardized, and with this, the Privacy wording for each these classes of apps is standardized as well — all with the goal of making such wording very clear and easy to understand, standard, and referenceable — similar in idea to how licenses such as GPL, MIT, Apache have been defined, standardized and used all around.

    With such “standardization”, mobile apps would have a very clean, simple privacy policy that is familiar in wording and meaning, for example:

    Privacy Policy — this application:

    1. Collects Data
    2. Shares data
    3. Tracks the user

    Please click on the appropriate hyperlink for more information.

    I would seeing an initiative of some kind to do just this (I’m investigating this as we speak). If you have any thoughts, please drop me a line. Perhaps there is something out there already that I haven’t seen yet. If there is nothing there yet, I believe it is worth it to follow up on this and come up with simple, consistent, familiar privacy messaging (and badge?) across platforms and applications.


    Personal and sensitive information include any information that is critical for a user, for example credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Any such information must be properly handled and secured.

    As privacy continues to become more critical over time, with the number of apps exponentially increasing, and with potential legislation in the future, having clear privacy and security wording/messaging and responsibilities is very important. And as product owners and developers, you/we are responsible!



    20 Jun

    Google I/O Extended Austin (2012)

    While the major Google I/O fun is happening in San Francisco on June 27-29, some of us will stay behind and run/participate at the Extended version of Google I/O — in my case, Google I/O Extended Austin.

    You can sign up for Google I/O Extended Austin — for registration and information visit https://sites.google.com/site/austinioextended/.

    We expect close to 50 people and we will have 3-5 speakers on June 27; yours truly included. I will cover “Security on (Android) Mobile Applications”.

    Related to this see Countdown to Google I/O: Diverse perspectives.


    31 May

    Introduction to jQuery Mobile (May 2012)

    See my latest article, Introduction to jQuery Mobile (developerWorks).

    This article, an update to my original Intro to jQuery Mobile (Feb 2011), introduces the basics in the latest version of jQuery Mobile. Learn about browser support, the UI components, and the API.

    “Summary: Get an introduction to the jQuery Mobile framework. Learn the basics of the framework and how to write a functional mobile web application user interface. In this article, an example guides you through basic pages, navigation, toolbars, list views, form controls, and transition effects.”

    Link: Introduction to jQuery Mobile (developerWorks).

    Related links:
    * jQuery Mobile developer site
    * Original article: Intro to jQuery Mobile (Feb 2011)