Application Security Part II: What Should App Developers Do?

[originally posted here for BlackBerry DevBlog on 2/6/13]

 

 

In my previous blog post on this topic, titled “Application Security Part I: Whose Responsibility is it?”, I explored the responsibility of security in the mobile app ecosystem.  In this post, let’s take a little deeper look at the problem of security and code safety from a mobile app developer’s point of view and explore what developers need to think about and how they can avoid potential security problems in their applications.

The majority of security problems in app development are really software quality problems. There’s something wrong with the way the code was written that leaves a door open for someone to exploit.  Fortunately, many of these problems can be easily fixed.  Some of these can be fixed in the design phase of product development and others in the code phase.  We’ll explore a few examples of each type in this post.

The Objective of this Post

Now, before we jump in, I need to confess that this is a broad and deep subject.  My goal here is to present a high-level understanding of code security through discussion and a few examples that will help you understand the kinds of vulnerabilities that can lead to problems.  I will also provide references to further reading for those that really want the “Full Monty” on developing secure apps.

Code Security at Design Time

·        Design with security in mind.  This is perhaps the most important thing you can do. Think about the following questions before you design your code and have answers for all of them:

a)     What Assets does this software need to protect?  Credit Card numbers, user data, contact lists, account info, access to paid services, and privileged access to device.   To protect sensitive assets, you need to plan how you’re going to deal with the data at design time.  If you’re sending sensitive data over a computer network, you should use SSL/TLS protocol to prevent attackers from eavesdropping. Look into OpenSSL for open source libraries and code examples on how to use this protocol.  Also, for server-side storage, consider using a 3^rd party database such as MySQL. These systems have their own built-in security policies that you can leverage.  Also, for secure authentication, leverage trusted services like OAuth and OpenID (See Additional Resources for more info below).

b)     How might an attacker exploit my code?  This is often called “Thread Modeling”.  Attackers might be eavesdropping on the network ports you use, or providing unexpected inputs that overflow memory buffers and inject attacker-supplied code to be executed. You have to ensure, for example, that you never execute code on behalf of an untrusted user.

2.      Follow a Secure Coding Standard - Select a secure coding standard and make sure your code conforms.  A secure coding standard will identify specific issues with a particular programming language that a compiler or analysis tool might fail to diagnose.  Secure coding standards also define requirements for producing code level security in your system.  Several popular secure coding standards are available from CERT® on their website at www.securecoding.cert.org.

3.      Perform Design Reviews.  This is a simple thing teams can do, and it can really pay off in the long run.  A few years ago, I managed a couple of engineering teams at Sun and when a new code module was planned.  The engineering lead would present the design to a team of Senior Architects with different backgrounds (JVM, networking, platform architecture, etc.).  This always uncovered potential problems –and did so early on before they became big problems that were expensive to fix.

4.      Understand Emerging Threats.  Pay attention to the type of exploits that are popular, and make sure you’re not helping the bad guys.   Designate one person on your team to stay up to date on the current security trends and put her/him in the code review. A great place to start is by visiting the CERT website frequently and becoming familiar with all the resources they offer.  In addition, all major platform and OS providers publish security updates from time to time as issues are uncovered.

5.      Use Static Analysis Tools.  Static code analysis can really help locate many kinds of software validation and reliability problems, including many memory problems. Some examples of companies that provide these products include:  Klocworkand Coverity, Parasoft, and Vericode. A more complete list can be found here: http://www.cert.org/secure-coding/tools.html 

If you’re doing all these things, you’re actually doing pretty well.  You’ve got a solid design, you’re following a secure coding standard, you’ve got someone keeping an eye out for potential security exploits, and you’re conducting design reviews and running static analysis tools on a regular basis. You’ve got the design side covered pretty well.  Now let’s look at some specific code issues that can cause problems.  

Code Security at Development Time

Most of the following examples demonstrate some of common problems found in native C and C++ development.  Web developers and Java developers can still benefit as the concepts behind the problems are valid in many languages.  In the Additional Resources section below, I provide links to specific Web and Java resources for code security. 

1)     Application Frameworks 

Use application frameworks whenever possible.  Frameworks hide a lot of the nasty memory management and secure network connection issues from the developer and reduce the possibility of making simple, but costly, mistakes.  Fortunately, the BlackBerry platform supports a lot of great developer frameworks, both from BlackBerry (such as the Invocation and Share Framework, and the UI Framework Cascades) and through BlackBerry’s Platform Partners.  

2)     Memory Management

Aside from the obvious allocation of memory insufficient for the data you’re writing into it, there’s a common issue people new to C and C++ sometimes experience regarding memory management.  The problem occurs when you confuse which action you use to release the memory you’ve allocated.

Using Cascades will reduce the likelihood of memory management problems because it hides all the messy details for you within the framework.  However, if you must allocate memory yourself for your app, keep the following tip in mind.

There are two main C functions for allocating memory: malloc() and calloc().  Use malloc() when you don’t care about initializing the data in memory.  Use calloc() if you want to initialize the memory to 0.  The important thing to remember is when using either malloc() or  calloc(), you must use the function free() to release the memory and give it back to the system. 

In contrast, when using the C++ method new() to create a new object, you must use the corresponding delete() method.  Nothing good can happen when you call free() on memory you’ve created using new().

3)     Function Safety

The QNX platform provides a number of preferred C functions that are safer to use than the more commonly known standard functions.  A subset of these is shown in the table below.  You can find the complete list in the BlackBerry Native SDK online docs (referenced in Additional Resources section below).

As with memory management, using an application framework helps with function safety as well.  For instance, the Cascades classes such as QString and QByteArray protect you from many of these problems as well.

As you’ll see in these examples, most of the serious problems occur when buffers you’re reading into or writing out to are not large enough to take the data.  These functions below help you from over-writing some of the time.  You should always perform bounds checking if you want to be on the safe side.  

Unsafe Function(s)	Preferred Function(s)	Comments
strcpy() and strncpy()   strcat() and strncat()	strlcpy() and strlcat()	The function strlcpy() copies strings and the function strlcat() concatenates strings. They're designed to be safer, more consistent, and less error-prone replacements for strncpy() and strncat(). Unlike those functions, strlcpy() and strlcat() take the full size of the buffer (not just the length) and guarantee to NUL-terminate the result (as long as the size is larger than 0 or, in the case of strlcat(), as long as there's at least one byte free in the destination string). There also exist "wide" versions of these functions that are equally dangerous: wcscpy(), but there is no "l" safe version to use, only wcsncpy() which does not necessarily NUL-terminate the output. Care must be taken to ensure the output buffer is NUL-terminated.
sprintf() and vsprintf()	snprintf() and vsnprintf()	The snprintf() function is similar to fprintf(), except that snprintf() places the generated output (up to the specified maximum number of characters) into the character array pointed to by buf, instead of writing it to a file. The snprintf() function is similar to sprintf(), but with boundary checking. A null character is placed at the end of the generated character string.
gets()	fgets(buf, n, fp)	The fgets() function reads a string of characters from the stream specified by fp, and stores them in the array specified by buf, limited to size n.
getwd()	getcwd(buffer, size)	The getcwd() function returns the name of the current working directory. buffer is a pointer to a buffer of at least size bytes where the NUL-terminated name of the current working directory will be placed. The maximum size that might be required for buffer is PATH_MAX + 1 bytes

 

4)     Structures

Structures in C and C++ are aggregated types that define and contain other data elements within them.  The elements of a structure cannot be re-ordered by the compiler.  Modern compilers do use a variety of methods to minimize the security risk of stack-buffer overflows such as stack canaries, address-space layout randomization, re-ordering the local variables within a function, among other things.  However, since the compiler can’t re-order the elements within your structures, the possibility of a buffer overflow on one of your elements affecting function parameters or local variables remains.  Consider the following example:

        struct _JOB {

            char name[64];
            char title[64];
            DATE startdate;
            DATE enddate;
            WAGE salary;     

        } JOB, *PJOB;

The buffers name and title can both overrun.  Since they’re placed on the stack first, the elements defined after them in the structure and on the stack itself can be affected.  For this reason, care should be given when defining the elements in a structure.  The next example shows a structure that's defensively designed:

        struct _JOB {

            DATE startdate;
            DATE enddate;
            WAGE salary; 
            char name[64];    // Buffers placed at end
            char title[64];   // of struct definition

        } JOB, *PJOB;

 

Recommendations for using structures

When dealing with structures that contain fixed-width buffers or arrays designed to receive data that's controlled or influenced by a user:

·        Buffers and arrays in structures should be grouped at the end of the structure

·        Local variables declared as structures should be declared after local buffers but before any other local variables

·        Global variables declared as structures should be declared before any global buffers and arrays and after any other global variables

·        Pointers to structures do not need any special consideration

·        Where practical, try to minimize the number of local variables cast as structures with buffers and arrays as elements

5)     Macros

Macros are one of my favorite mechanisms in C and C++.  I love using them; however, you have to be very careful as they can get you into trouble.  Macros are defined through the use of the #define preprocessor directive and when processed, literally expand in your source code prior to compilation.  If IDE’s could show you what the processed source code looked like (maybe some do?), then I suspect we’d see fewer problems.  Consider the following example that demonstrates the issue:

#define CUBE (x*x*x)

…

int x = CUBE (5-2)

In this example, you might expect that you’re going to get the cube of 3 which is 27.  However, when the preprocessor expands the macro, normal operator precedence rules apply.  So, here’s how that the value of x will be calculated: 

CUBE(5-2) = (5 – 2*5 – 2*5 – 2)

CUBE(5-2) = (5 – 10 -10 -2)

CUBE(5-2) = -17

Therefore, to protect against this problem, the macro can easily be defined using parentheses as in:

#define CUBE(x)   (x)*(x)*(x)

In this example, we’ve seen how operator precedence rules can get you into trouble with macros.  There are other problems such as the importance of white space when defining macros, using macros in if statements, and self-referencing macros to name a few.  Provided you think about how the macro will expand in your source and you consider how the arguments you pass to macros will be interpreted in that expansion, you should be fine.

6)     Integers (signed, unsigned) and Enumerations

Another common problem that can expose serious threats to your code involves integer overflow or underflow.  This can happen when care is not taken with integers.  The following code fragment demonstrates how serious this problem can be (recall our discussion about buffer sizes above):

int buffLen = 0;

printf(“[buf] %d %u\n”, buffLen, buffLen);

buffLen = -1;

printf(“[buf] %d %u\n”, bufflen, bufflen);

Executing this code gives:

[buf] 0 0

[buf] -1 4294967295

In this example, I forced the value of bufLen to be -1 for demonstration purposes.  But, it’s easy to imagine a simple arithmetic error in a length calculation to be off by one.

Similar problems arise with the use of Enumerations.  Not all compilers use the same kind of “int” for Enumerated types.  So, you need to be careful when using Enumerations.  Make sure you know how your compiler treats them.  If your compiler uses signed integers by default (such as Microsoft Visual C++ and ARMCC), it’s not possible to create an unsigned enumeration as the value will be overflow the signed int (for example, you can’t set the enumerated value to be 0xffffffff).

Summary

Though we’ve just scratched the surface of this topic, we’ve discussed a number of things developers can do to protect their code from security problems.   We’ve explored good practices developers can adopt at design time, such as:

·        Design with security in mind

·        Follow a Secure Coding Standard

·        Perform Design Reviews 

·        Understand Emerging Threats

·        Use Static Analysis Tools. 

We’ve also looked at some common coding mistakes that can lead to security problems and discussed how the code can be fixed to avoid these problems.  We’ve seen how leveraging Application Frameworks (like Cascades) can greatly reduce security problems.  As an app developer, you have a responsibility to protect your user’s identity and sensitive data as best you can from attackers seeking to exploit it.  The content in this blog post should help you get started with some good practices and links to learn more. 
For more information on application security, additional examples, and deeper analysis, please refer to the additional resources below. 

Additional Resources

·        BlackBerry Native SDK Online Docs.  Security Considerations for Native Application Development

·        QNX Online Docs, Neutrino C Library Reference

·        Chad Tetreault, Say It Aint S’OAuth,  in BlackBerry Dev Blogs

·        Software Engineering Institute | Carnegie Mellon  http://www.sei.cmu.edu/ 

·        Seacord, Robert. The CERT C Secure Coding Standard, Addison Wesley, 2008

·        Seacord, Robert. Secure Coding in C and C++, 2^nd Edition, Addison Wesley, 2013.

·        Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment

Acknowledgements

I’d like to thank Robert Seacord for taking the time to read an early draft of my blog and provide helpful feedback.  Robert is a senior analyst in the CERT® Program at the Software Engineering Institute (SEI) in Pittsburgh, PA where he leads the Secure Coding Initiative and is author of a number of books on Secure Programming.  I’d also like to thank the BlackBerry Security team for their insightful comments and suggestions.

Application Security Part I: Whose Responsibility is it?

[originally posted here for BlackBerry devblog on 12/6/13]

 

 

This is the first post in a two part series about security.  In this post, I tackle the issue of responsibility. In Part II, we’ll explore some things that developers need to know to help them write secure apps.

I sat on a panel recently at Sprint’s Open Solutions Conference in San Jose titled,  “Consumer Application Security for Developers”. Sexy topics like application security rarely pack a session hall at any conference and this was no exception.  However, the attendance was much higher than I expected (about 30 people) and the discussion was very lively and interactive.  It was immediately clear to me that developers –perhaps as consumers themselves-- are thinking more about security than they had in the past.  This is a good thing.

Whose Problem is Security?

One of the first questions that came up in the panel was “Whose Problem Is Security”?  Our moderator suggested a number of potential “owners” for this problem and posed the question to his panel.  Is it the carrier’s problem?  How about the Handset OEM?  The OS?  Your Employer’s IT Admin?  The App Developer?  The Consumer?  As you can see, there’s a lot of parties to point fingers at when something goes awry. 

I couldn’t help but jump on this one first.  The answer is obvious: Security is everyone’s responsibility.  Each player in the mobile device value chain is responsible for providing a secure environment over the part they control.  At its most fundamental level, security is about protecting valuable assets from those who seek to steal or exploit them.  You wouldn’t leave your house in the morning without locking the door, right?  Even greater diligence is required in the digital world because the value can be greater, and the thieves are invisible.

Security is everyone’s responsibility

The Carrier: The carrier is responsible for providing a network that is secure from being attacked, snooped, or otherwise compromised.  As carriers reduce their investments in their own app catalogs, their responsibility with app security lessens but responsibility for cellular and data network integrity remains.

The Device: The device’s operating system (OS) is at the center of security. The OS’s responsibility is to provide a secure environment for all applications, services, data storage, and network connectivity.  The OS is responsible for handling permissions and defending against viruses and malware.  Attackers primarily seek to exploit weaknesses in the OS or in its core applications such as web browsers.  This is why it’s so important to design security into the OS when it’s being architected and built.  Platform providers that offer App Stores have an additional responsibility to ensure that the apps it stocks in its store are safe from malware and abuse like piracy.  It should be no surprise to anyone that RIM takes the issues of security very seriously.

The IT Administrator: The number one responsibility of IT at any high-tech company is protecting the company’s Intellectual Property (IP) –it’s like the crown jewels of the company’s value.  In a world where IT administrators directly managed the mobile devices that had access to the company’s jewels, their ability to protect them was pretty clear.  However, with today’s BYOD trend, their ability to protect the company’s assets and IP has become less clear.  Only RIM has addressed this uncertainty and given control back to IT administrators and CIO’s with its BlackBerry Mobile Fusion (IT’s MDM Portal) and BlackBerry Balance (the client side partitioning; controlled by a simple gesture).  With these products and services, IT administrators can enforce corporate security policies and manage remote devices with confidence.

The App Developer:  App developers have a responsibility too.  It’s their job to build an application that can’t be exploited by attackers and protects sensitive information that the user provides.  Strong operating systems provide many mechanisms for app developers to ensure their app isn’t the “unlocked window” that gains access to someone’s identity or bank account.  App developers need to think about security as an end-to-end problem.  This includes making secure network connections, encrypting local data on the device, and ensuring servers with sensitive customer data are adequately protected from attack.

The Consumer:  Consumers need to be mindful as well. Use device passwords (and not “1234”) and, perhaps most important of all, be suspicious of applications asking for permissions to access files, social networks, and your contact list. RIM offers a great product for consumers called BlackBerry Protect that helps keep the information on your device backed up and secure should your device get lost or stolen.  BlackBerry Protect also allows you to wipe all the data off your device remotely as well as display an alert message on the home screen should you lose your BlackBerry.

Why is BlackBerry 10 so secure?

BlackBerry 10, RIM’s upcoming mobile computing platform set to launch on January 30^th, 2013 is built on QNX’s Real-Time Operating System.  Sebastien Marineau, VP of OS Platforms at RIM, wrote a great article recently titled: “How BlackBerry 10 avoids Android’s Security Issues”.  In the article, Sebastien notes that the QNX RTOS has approximately 100,000 lines of code whereas a standard Linux implementation is around 14 Million lines of code.  QNX is 1% the size of Linux.  When it comes to security, the fewer places where bugs and security exploits can hide, the better!  Because QNX is so tight, and because it’s been designed with security in mind from day 1, it’s extremely hard to break in. 

In addition, BlackBerry 10 includes BlackBerry Balance: a new, unique, and innovative capability that allows consumers to enjoy the full range of both a personal mobile device and a secure, encrypted work device without compromising on either one.  No other mobile device can do this.  With one simple gesture, the user can switch the device from “Personal” mode (wide open with all their apps, music, media, etc.) to “Work” mode (fully secure as if on your work’s VPN).  Using BlackBerry Mobile Fusion, IT Administrators can manage their company’s devices remotely and securely (including Android and iOS devices!).

What's next?

In this blog post, we explored the responsibility of security.  Who owns what piece and why it’s so important.  My next post on this topic, titled “Application Security Part II: What Should App Developers Do?” will explore different things developers can do to make sure they’re writing solid, high quality, secure mobile applications.

Accountability in the Media

I suspect that when printed media was a fairly new thing, people trusted what was written more than we do today. Over the years, however, we've become pretty good at weeding through the fact and fiction that we see, hear, and read about in our mainstream media. The current election coverage is a rich example. In contrast, we remain fairly trusting of the technology news we read today. We're not attuned to filtering and questioning the bias here like we are with mainstream media. Is this a healthy thing? Technology is, by definition, technical. Therefore, it should just be facts, plain and simple, right? When someone in the tech media reports that a certain chip operates at 1.5GHz, or that a company's new platform release date is slipping, we have no reason to doubt that fact. Technology is what technology is. Or, is it?

 

Lately, I’ve been seeing more and more opinion (and terribly uneducated opinion) passing as fact in our technology media. I think this is primarily driven by 2 factors:

1. With more and more "writers" and access points to the news (tablets, smartphones, etc) there's a lot more competition for our attention so sensationalism is creeping in to acquire and retain readership.  A good friend of mine, and ex-news cameraman, reminded me recently that the mantra in the media has always been "If it bleeds, it leads".  That explains so much.
2. Our relationship to technology is becoming much more personal causing people to inject their personal bias into their technology reporting.  If you're following the news about BlackBerry, iPhone, Android, and Windows Phone, you'll know what I'm talking about.  The "news" is almost more like reporting religion than it is facts.

 

What's most disturbing to me, however, is how much power technology analysts and journalists have.  Writers that don't double check their sources or fact-check their data before they rush to print can actually cause significant material impact to shareholders and companies and they have virtually no accountability.

 

A good example of this is the October 9th statement from Jefferies analyst Peter Misek where he states that BlackBerry 10 will likely slip into March. This gets picked up by Forbes, PC Mag, Bloomberg, Yahoo News, AllthingsD, etc. and very quickly markets react.  Was there any news here? No. RIM, my employer, stated quite consistently that it's targeting release of BlackBerry 10 in Q1 2013. Yet one analyst decides he'll spin that information into a “slip” and causes real material impact. Here's the Forbes blurb:

 

Research In Motion: No BB10 Debut Until March, Analyst Says

http://www.forbes.com/sites/ericsavitz/2012/10/09/research-in-motion-no-bb10-debut-until-march-analyst-says/

 

Fortunately, there are responsible analysts out there that call him on it, but the damage is done.  Here’s a good example of someone else in the industry refuting his claim:

 

BlackBerry 10 delay refuted

http://www.ubergizmo.com/2012/10/blackberry-10-delay-refuted/

 

One might argue that the industry is doing a good job of self-regulating as demonstrated by the two links above.  However, I say it’s not enough.

 

Now, the First Amendment guarantees freedom of speech, and freedom of press, etc. so, we can't keep people from writing whatever they want. However, we can try to hold them accountable. Here's what I propose:

 

Accountability for Tech Media:

1.     Each tech journalist and analyst gets rated by their readers and the industry over time. We're all used to rating apps we buy, pics our friends post on FB, books we read, sellers we’ve purchased from on eBay.  We even rate each other’s comments on tech forums. Why not rate the analyst’s predictions and their technology coverage? If they say something that turns out to be true, they get credit for that. If they say stuff that turns out to be false, they get dinged for it.   

2.     The rating should measure the analyst's Accuracy, Ability to Predict the future, and the Relative Bias we see in their work.  Meaning is it balanced or typically slanted in one direction all the time.  So, in the example above, the Jefferies analyst would have received a number of ratings that demonstrated the point they were making was not accurate (there was no slip) and potentially biased (what was the motivation of this non-news piece?).

3.     Statements made by Analysts moving forward would then be tempered by their industry rating. For instance, an analyst that checks their facts, makes generally good predictions, provides useful information, and tends to be fair and balanced in their coverage will have a strong rating and therefore warrant more attention when they make bold statements. Investors can react with confidence. Conversely, analysts that tend to the sensational, don't check their facts, and are generally seen as providing biased information will get low ratings. Markets and investors would easily know to take their comments with a grain of salt.

4.     People that rate others can also develop a rating based on how often their rating correlates with the industry's rating.  Thus, informed readers can develop credibility as well over time.

The beauty in a system like this is that it adds accountability. People are still free to say and write whatever they want. The difference is that now we have a rating to help us decide whether to react to the comments made by these people or not.  Also, by holding these guys accountable, analysts and tech journalists will double check their facts more and this can only have a positive impact in the quality of the news and information they deliver to us.

 

If you like what I’ve written, rate this piece!  J

 

--Larry

Misconceptions about BlackBerry...

As an evangelist for BlackBerry, I often find myself in front of audiences full of people with lots to say about RIM and BlackBerry.  I hear and read lots of commentary, and though a lot of it is repeated over and over, most of it is just plain inaccurate.  In my 20+ years in high tech, I've never experienced a topic so heavily covered by the media and yet contain so few facts.  I think this is partly due to the fact that as a society, we've become like religious zealots about our mobile devices. Our phones have become extensions of our identity or personality, and thus take on an emotional attachment, exempt from objectivity and fact checking.  So, in the interest of education, I'll share with you some of the misconceptions I hear all the time along with my perspective about what's real...
 

Here are some of my favorite uninformed statements:

1. "RIM is dead" or "RIM is going bankrupt"
2. "BlackBerry 10 is 'too little too late'"
3. "BlackBerrys are for business"
4. "BlackBerry doesn't have any apps"
5. "BlackBerry should just adopt Android"

 

1. "RIM is dead" or "RIM is going bankrupt"

First, some facts:

• RIM has $2 billion in cash
• RIM has no debt
• RIM owns all its buildings/real estate
• RIM is growing in subscribers and app developers  
• The internal culture at RIM is very strong

I believe this misconception stems mostly from RIM's loss in US market share.  The sentiment that RIM is going bankrupt or that it's dead is uniquely a US thing.  BlackBerry is thriving in other parts of the world quite well.  It's the #1 device in Latin America (all countries) and BlackBerry enjoys an insane fervor in Indonesia where people camp out at BlackBerry stores the night before a new device launch and seek RIM employee autographs when we hold conferences and events there.

The US, however, holds the worldwide megaphone for news in the smartphone sector, so that's what we hear.  It's certainly true that the market share for of BlackBerry devices has decreased dramatically over the last 3 years from a peak of 20% in 2009 to about 5% in 2012.  So, it's understandable why someone would come to the conclusion that RIM is dead or going bankrupt.  However, there's a lot more going on here than people realize.  First, the market share is so low in the US because we don't have a device in the portfolio that meets the needs of the US market right now.  The US market wants a thin piece of glass, GPU-accelerated graphics, all touch, with lots of apps on it.  I agree we should adapted to this trend a lot sooner than we did.  However, what we did was decide to take the hit in the short term and step back, rebuild, and plan a leap-frog strategy.  And that's exactly what we've done with BlackBerry 10. 

It started about 2 years ago with the acquisition of a few companies strategically designed to create a new BlackBerry platform.  These critical acquisitions include:

• QNX.  Arguably one of the best RTOS's in the world.  QNX runs in 60% of the cars on the road today, it's in Cisco's largest multi-core Internet routers, most of Las Vegas's gambling machines, the space shuttle, and a majority of the world's nuclear power plants.  It's a battle-tested, high performance, multi-tasking, beast of an OS that thrives in life-threatening real-time situations.   This new OS, at the heart of BlackBerry, is strong enough to power innovations in mobile computing for the next 10 years.  BlackBerry 10 is much more than a smartphone OS as will become more clear over time.  QNX's connection to the auto industry (see CES award) will bring innovations to the smartphone-car interface that go well beyond what is available today.
• Torch Mobile.  Torch mobile is one of the world's most active contributors to Webkit for mobile devices.  Webkit is the rendering engine used in all of today's major browsers (Safari, Chrome, Android Browser, Opera, etc.).  More recently, this acquisition has helped to create a killer browser for BlackBerry 10, and has catapulted the BlackBerry browser and the BlackBerry web platform (called WebWorks)  to the front of the HTML5 compatibility race.  An increasing number of companies that are betting their mobile future on web technologies are building on BlackBerry PlayBook first and porting afterward to more constrained web browsers found on iOS, Android, etc. 
• TAT (aka, The Astonishing Tribe).  This Swedish Design shop is a crazy bunch of UI/UX designers!  These guys designed the UI for the Google G1 phone, and have developed a tool chain based on Qt and QML for building extremely, dare I say "astonishing" user interfaces.  Since the acquisition, they've been working closely with our User Experience team (headed by Don Lindsay, ex Design Director at both Apple and Microsoft) to create a UI and UX tool box to enable app developers to very easily build rich and compelling BlackBerry 10 apps.

So, YES, the market share has been hit hard while we've been rebuilding.  The important question is this:  Is the declining market share indicative of RIM's demise, or is it a temporary phenomenon necessary to endure while we build a new, really great platform?   I think you can guess where I stand on that question.  :-)

Another  thing that baffles me when I think about people on the outside looking in, is they're very quick to make blanket statements about a company's health based on a stock price or a quarterly earnings statement.  Stock prices are based on pubic faith about your future.  With so much misinformation out there about RIM, it's hardly a reliable guide.  Similarly, earnings reports represent rear view mirror sales.  When you're building a new platform, you can't base the viability of the new stuff based on how the old stuff performs.   

To get a good picture about a company in the midst of a turn-around, you have to dig deeper and ask these kinds of questions:

• Are they making the right changes at the top?  Answer:  YES.  All new C-level execs, energized, focused, and aligned.  There's a plan, and we're following it. 
• Is key internal talent leaving?  Answer:  NO.  The key architects involved in the core BlackBerry 10 teams are all staying put. This includes hardware, software, tools, user experience, etc.  This is a very exciting time to be at RIM.
• Do they have the capability to bring the new stuff to market? Answer:  YES. QNX, Torch, TAT, and much more are very formidable forces.  The tech is  definitely there.
• Do they have the manufacturing and distribution channel in place?  Answer:  YES and YES.  The carriers love it and want it now.

2. "BlackBerry 10 is 'too little too late'"

Let's break this one up into two pieces because neither is true.
 

"BlackBerry 10 is too little" 

This kind of statement is, of course, subjective.  What's "too little"?  Your "too little" might be different from my "too little".  So, let's try to make this less subjective by considering not our opinions, but the opinions of the people in the industry that buy these devices in large quantities: the Carriers.  We've not divulged the names of the carriers that have committed to BlackBerry 10 yet, but our executives have been sharing BlackBerry 10 with major carriers, and there's some news out there about it:  :  RIM gives Canadian carriers a look at its new BlackBerrys.  Suffice it to say, it's definitely not too little.  The carriers LOVE it. Why?  it's innovative.  It's not the same user paradigm that Apple brought to the market 6 years ago.  A lot has changed in technology since then, and BlackBerry 10 --whether you want to believe it or not-- is really innovative.  You'll find that you can get a lot more things done on your device in less time, less clicks, less remembering where you stuffed which pieces of information.  A common message that we're hearing from people that are using it today is, "after using BB10, I find the <insert your favorite other smartphone name here> to be clunky and slow"
 

"BlackBerry 10 is too late"

This one always makes me laugh.  Like, yeah, the final chapter on smartphones has been written.  Last time I checked, only half the addressable market in the US (and we lead the world here) is using a smartphone.  If you think it's too late because of money, read #1 above. 

So, notwithstanding the fact that people change phones ever 2 years and that many people still love BlackBerry, China is not online yet, and here's the critical one...   [wait for it....]   people are getting fatigued with Apple.  The devices all look and act pretty much the same.  The in and out of apps use case hasn't changed in 6 years.  The most recent Samsung commercial cracks me up.  I have to give Samsung credit, they've totally captured it.  "The headphone jack is going to be on the bottom!"  ROTFL...  I really think people are starting to look for, dare I say it, something "different".   Too Late?  I think not.  There's plenty of market share out there and this industry is still in it's infancy.  There's lots and lots of innovation yet to be delivered.      

3. "BlackBerrys are for business"

Historically, this was the case.  However, about 2 years ago, the number of subscribers using BlackBerrys for consumer use exceeded business use for the first time and has continued to pull away.  In addition, the classification that a device is for business or pleasure no longer makes sense. 

The BYOD (Bring Your Own Device) trend we've all seen with smartphones has shown us that people want to carry one device around with them.  There is no work device or personal device.  In response to this trend, RIM has taken a leadership role in the smartphone industry with respect to BYOD with 2 products:

• BlackBerry Balance
• BlackBerry Mobile Fusion

BlackBerry Balance is a capability on newer BlackBerry devices that allows them to separate -in a very secure way- a person's personal data and apps from their sensitive work data and apps.   BlackBerry Mobile Fusion is a professional grade device management system.  It offers a web portal for IT administrators that allows them to manage iOS, Android, and BlackBerry devices at their company.  Most IT departments are familiar with BlackBerry's Enterprise Solutions and recognize this brand as secure and trustworthy.  These two products are innovative BYOD features and capabilities that set BlackBerry apart from other platforms.   

BlackBerry 10 devices are high performance, GPU accelerated, multitasking machines that will allow users to play games and quickly check email without leaving the game app.  Once you see it, you'll know what I mean.   So, if you've not seen it, watch this:  BlackBerry 10 Demo

4. "BlackBerry doesn't have any apps"

If you're using an older BlackBerry, one running BB4 or BB5, this is definitely true.  And, unfortunately, there are still a lot of people using older devices.  My sister-in-law is a nurse at a big hospital chain in California and was just given a BlackBerry by her employer.  She was having trouble getting the device to do something, so she handed it to me to "fix".  My first realization was that the OS was so old, I didn't remember how to do said function on that old OS.  This is part of the problem.  Many of the devices out there are from another era...  A time before app stores.

The fact is that there are over 100,000 apps in BlackBerry App World.  Just about everything you need is there.   And BlackBerry 10 will have tons of apps. The app count comparison was interesting in the early days of smartphones, but I don't believe it has any meaning anymore.  PC World wrote a great article on this titled "Why the Number of Apps in an App Store Doesn't Matter".  They found that there's over 1200 versions of solitaire in Android Market and over over 900 in apple app store.  When you remove all the duplicates, all the stores have about the same number of unique apps. So, the main problem with the app counting metric is that it counts all the duplicates, all the fart apps, all the junk apps that get accepted into app stores often without any curation.   One market place (I don't need to mention which one) doesn't do any checking to see if the app someone is uploading is actually their app (sounds crazy, right?) or whether it contains IP that doesn't belong to them or viruses that could hurt unsuspecting consumers. 

The BlackBerry App ecosystem is healthier than ever.  Vision Mobile recently reported that BlackBerry is most profitable app platform for developers (Vision Mobile Developer Economics 2012).  They found that not only does BlackBerry pay more on average per app than both Apple and Google, but it also costs less to develop the apps.  Mobile developers are smart people and know how to follow the money.  Consequently, we've had more vendor registrations in the last year (a 229% increase over last year) than every before and the number continues to rise.  On the consumption side, we've also enjoyed acceleration in app downloads.  Recently we hit 3 billion downloads for App World.  This happened in less time that it took to get to 2 billion which was less time that it took to get to 1 billion.  

Keep this thought in mind:  These numbers are all for our old BlackBerry OS based devices.  Imagine what will happen when we have a kick-ass, competitive and differentiated BlackBerry 10 device in the market Q1 next year.   

5. "BlackBerry should just adopt Android"

This argument is, in my opinion, the least informed of the whole bunch.  Here's why:  If RIM were to adopt Android, it would be a death sentence.  A slow and painful certain death --not to mention a colossal waste of innovation.

Here's a question that I hope will illustrate the point for you:  If you were the CEO of RIM and could do either of the following, which would it be:

A) Adopt Android and get in line with all the fragmented, un-differentiated devices out there whose primary purpose is to deliver ad revenue to Google, or

B) Create a differentiated, innovative, new platform that provides real value not addressed by any other platform 

Now, I think most rational people would choose "B".  The sentiment that's causing some people to say "A" is that they just don't think B is possible.  They've given up on B as an option.  The fact is, B, is what we're doing.  It's what we've been building since we acquired QNX. 

Other people will say, "No, it's not Android.  What RIM needs to to win back market share is more apps".  

Well, more apps (though important) isn't going to do it either.  What's needed is a truely great user experience.  Something that makes consumers say, "I _need_ that device".  It's designed to help people get of stuff done more easily and quickly.  It's a revolution in the smartphone user paradigm.  Starting from scratch, we designed a platform that addresses how people use their devices today.  If you're a productive person, or someone that strives to be successful or creative, then you'll find the BB10 device the one you'll need to have.   See #1 and #2 above for more background. 

--Larry McDonough   @lmcdunna

Head of Platform Evangelism, Americas,
Research In Motion
Silicon Valle

The Great Stir Stick Conspiracy...

Like many people, I drink a lot of coffee. I find myself wandering into a Starbucks, Peets, or my local Los Gatos Coffee Roasters quite often (usually multiple times a day) and it never seems to iritate me that the cream and stir sticks are always at the end of the line --the assumption being that you will pour your coffee first, and then add cream and/or sugar.

I've always hated this. It's like an extra step that you do at the end only because you haven't figured out that you can do without the step entirely if you just rearrage the order. There's no need for a stir stick if you put your cream/sugar in first. Then, when you pour your coffee in, it's mixes automatically. Viola!

At conference buffets it's the worst. I'm the guy you see take his cup, walk around all the coffee dispensors to the cream table, pour in some half & half into his cup, and then walk back to the coffee dispensors. Seems silly, but I've been doing this for YEARS (because it's well, just the right way to do it).

I asked myself... Why do we all accept this less-optimal process of cream & sugaring last? And then it occurred to me: It's the stir stick industry. They have a lot invested in this backwards process... If we all changed our behavior, the industry would collapse overnight.

I found this interesting blog by Bill True (http://billtrue.wordpress.com/2011/04/18/wood-stir-sticks-for-coffee-an-environmental-impact-analysis/) where he does an ad hoc environmental impact analysis on stir sticks:

"There are five stages in the lifecycle of a wooden stir stick: 1. Growing and harvesting white birch trees (the wood primarily used for stir sticks), 2. Manufacturing the sticks, 3. Distributing the sticks, 4. Using the sticks, 5. Disposing of/recycling the sticks. Although one could find red flags at any step in the process, the types of concerns raised in stages 2-4 are common across today’s commercial spectrum. The rise in the amount of white birch to accommodate increased demand, however, presents a real and immediate environmental concern."

It's very clear that there is a lot of money at stake here. So, I call on all my coffee-quaffing, environmenally-minded, process perfectionists like me to skip the swizzle stick, wood or plastic, and add your cream & sugar First!

--Larry