December 19th, 2012

Do You Agree to the Terms & Conditions? Mobile Devices & the Tipping Point of Informed Consent

Written by
 

End-User License AgreementSometimes, I wonder if anyone in the entire history of computing has every bothered to read and consider the contents of a typical end-user license agreement (EULA). Some Product Manager, I suppose (though truthfully, I’m not even sure of this one).

The EULA, however, is important. It’s the foundation of an vital consent ceremony that ends with only one effective choice: pressing OK. This much-maligned step in every software installation is the only real binding between an end user and a provider of software. Out of this agreement emerges a contract between these two parties and it is this contact that serves as a legal framework for interpretation should any issues arise in the relationship.

Therein lies the rub, as the emphasis in a EULA — as in so much of contract law — is on legal formalism at the expense of end-user understanding. These priorities are not necessarily mutually exclusive but as any lawyer will tell you, it’s a lot more work to make them coexist on a more-or-less equal footing.

Mobile devices may provide the forcing function that brings change into this otherwise moribund corner of the software industry. Mobility is hot right now and it is demanding that we rethink a wide span of business processes and technologies. These new demands are going to extend to the traditional EULA and the result could be good for everyone.

Case in point: the New York Times reported recently on a study conducted by the FTC examining privacy in mobile apps for children. The researchers found that parents were not being adequately informed about what private information was being collected and the extent to which it could be shared. Furthermore, many mobile app developers are channeling data into just a few commercial analytics vendors. While this may not sound like too big a deal, it turns out that, in some cases, these data are tagged with unique device identifiers. This means that providers can potentially track behavior across multiple apps, giving them unprecedented visibility into the online habits of our children.

Kid plus privacy equals a lightning rod for controversy but the study is really indicative of a much greater problem in the mobile app industry. Just the previous week, the State of California launched a suit against Delta Airlines alleging the company failed to include a privacy policy in its mobile app, placing it in violation of that state’s 2004 privacy law.

You could argue that there is nothing new about this problem. Desktop applications have the same capacity for collecting information and so pose similar threats to our privacy. The difference is mostly the devil we know. After years of reading about the appalling threats to our privacy on the Internet, we have come to expect these shenanigans and approach the conventional Web guarded and wary. Or we don’t care (see Facebook).

But the phone, well the phone is just… different.  Desktop computers — or even laptops — just aren’t as ever-present as phones. Your phone goes with you everywhere, which makes it both a triumph of technology and a tremendous potential threat to your privacy.

The problem with the phone is that it is the consumer device that isn’t. Apple crossed a chasm with the iPhone, taking the mobile device from constrained (like a blender) to extensible (like a Lego set) without breaking the consumer-orientation of the device. This was a real tour de force — but one with repercussions both good and bad.

The good stuff we live every day — we get to carefully curate our apps to make the phone our own. I can’t imagine traveling without my phone in my pocket. The bad part is we haven’t necessarily recognized the privacy implications of our own actions. Nobody expects to be betrayed by their constant companion but it is this constant companion that poses the greatest threat to our security.

The good news is that the very characteristics that make mobile so popular also promise to bring much needed transparency to the user/app/provider relationship. Consumer-orientation plus small form factor equals a revolution in privacy and security.

Mobile devices tap into a market so vast it dwarfs the one addressed by the humble PC. And this is the market for which consumer protection laws were designed. As we’ve seen in the Delta Airlines case above, the states have a lever and apparently they aren’t afraid to use it.

But legislation is only part of the answer to reconciling the dueling priorities of privacy and consent. The other element working in favour of change is size — and small is definitely better here. The multi-page contract just isn’t going to play well on a four-inch screen. What consumer’s need is a message that is simple, clear and understandable. Fortunately, we can look to the Web for inspiration on how to do this right.

One of the reasons I get excited about the rise of OAuth is because it represents much more than yet another security token (God knows we have enough of those already). OAuth is really about granting consent. It doesn’t try to say anything about the nature of that consent but it does put in the framework to make consent practical.

Coincident with the rise of OAuth on the Web is a movement to make the terms of consent more transparent. This will need to continue as the process moves to the restricted form factor of the mobile phone. I have no doubt that, left to their own devices, most developers would take the easy route and reduce mobile consent to a hyperlink pointing to pages of boilerplate legalese and an OK button. But add in some regulatory expectations of reasonable disclosure and I can see a better future of clear and simple agreements that flourish first on mobile devices but extend to all software.

Here at Layer 7, we are deeply interested in technologies like OAuth and the role these play in a changing the computing landscape. We are also spending lots of time working on mobile because, more than anything, mobile solutions are driving uptake around APIs. When we built our SecureSpan Mobile Access Gateway, we made sure this solution made OAuth simple to deploy and simple to customize. This way, important steps like consent ceremonies can be made clear, unambiguous and — most importantly — compliant with the law.

December 18th, 2012

New Mobile eBooks

Layer 7 eBooksAs a Partner Architect at Layer 7, I’m lucky enough to get to interact with some of the best and brightest in the industry. These include software vendors, systems integrators, analysts and thought leaders. When you add in our own experts, we have access to a veritable “who’s who” of the API world.

Recently, we began a series of free eBooks that will distill our communal knowledge into specific, targeted recommendations for dealing with a variety of challenges around APIs – from interface design, to security, to developer engagement. Today, I’m pleased to announce the first two of these, which deal with API exposure for internal mobility projects and for externally-facing open APIs.

First, we have Enterprise on the Go: 5 Essentials for BYOD & Mobile Enablement. This eBook focuses on the challenge of securely exposing internal applications and information assets to mobile employees, either on their own devices (BYOD) or as part of a larger mobility initiative. These five key points for a successful deployment are presented in an easy-to-consume synopsis and then backed up by white papers, webinars and customer case studies. Of particular interest to our enterprise customers are the sections on repurposing existing services and using middleware to optimize for mobile use cases.

Next, we have 5 Ways to Get Top Mobile App Developer Talent for your Open APIs. While not all enterprises have chosen to expose their APIs externally, those that have are faced with the challenge of acquiring a talented community of developers that will build useful mobile apps for the consumer marketplace. However, enterprises can’t simply assume “build it and they will come.” Getting devs onboard requires investment in documentation, branding and community development. This eBook discusses some of the best methods for onboarding and rewarding those developers who provide the most value.

Whether focused on internal or external developers, these eBooks are valuable resources for anyone looking to expose APIs for mobile access to enterprise assets. We welcome your feedback on this format and look forward to continuing the series.

December 11th, 2012

Clarifying “Hybrid Mobile App”

Hybrid Mobile AppsTomorrow, I’ll be presenting a webinar called 5 Ways to Get Top Mobile App Developer Talent for Your Open APIs. Preparing for this webinar got me thinking about different types of mobile app and how they relate to APIs. One thing that occurred to me was how loosely the term “hybrid mobile app” is used – I’ve seen it used to define two very different types of app.

1. Hybrid HTML5/Native Mobile Apps
The term “hybrid mobile app” is often employed to describe an app that is created using a WORA (write once run anywhere) framework like PhoneGap or Appcelerator. These frameworks basically make it simple for developers to generate mobile apps using HTML5, Javascript and CSS.

In the case of Phonegap this app will essentially be a “wrapped” Web site. For PhoneGap apps, developers will often use a UI framework as well, such as JQuery Mobile or Sencha. These UI frameworks look “good enough” on mobile devices, although they should not be confused with the true native UI controls of iOS, Android etc.

In the case of Appcelerator, the generated app can actually leverage the true native sliders, scrollers, date pickers etc. of the device OS. The limitation to this approach is that a developer is fully locked in to what Appcelerator provides. Currently it offers builds for native iOS and Android as well as an HTML5 build, which could potentially be run through PhoneGap.

2. Hybrid API-Driven/Thin-Client Mobile Apps
The term is also used to describe apps that are installed on and run entirely on the mobile device – similar to how a totally native, offline game or other app might work – but which rely on a data connection for presenting Web-based resources, enterprise application functionality or other information assets.

Of course, these information assets are made accessible to the apps via APIs, which is where Layer 7 comes into the equation. In tomorrow’s webinar, I’ll be mainly focused on hybrid mobile apps that are powered by APIs and discussing aspects that are important to address when developing an HTML5 hybrid native app that is also a hybrid API-driven native app. Click here if you want to find out more about the webinar or if you’d like to register.

December 7th, 2012

Use Hypermedia to Reduce Mobile Deployment Costs

Using Hypermedia to Reduce CostsI speak about the power and flexibility of hypermedia quite often. I explain the general idea behind hypermedia, discuss its historical roots and show how it can help client applications adapt to changes in data input and application flow. Essentially, a hypermedia-based approach aims to take key elements often placed into the client’s source code and move them into the actual response messages sent by the server.

I also point out that using a hypermedia-based approach to building client and server applications takes a different kind of effort than using RPC-style approaches. And I explain that, currently, there is a limited amount of tooling available to support the process of designing, implementing and maintaining hypermedia-style systems.

If your work involves designing, building, testing and deploying a mobile client application, it is likely you need to deal with an “application store” or some other process where your packaged application must be submitted for review and approval before it is available to users for download. This can happen not only with well-known public offerings such as the Apple Store but also within any organization that provides its own application repository aimed at ensuring the safety and consistency of user-available mobile apps.

In an environment of quick-turnaround, agile-style implementations this “app store” approval can be a real bottleneck. It may be not just days but weeks before your app is tested, approved and posted. This can be especially frustrating when you want to deploy a rapid-fire series of enhancements in response to an engaged user community.

A hypermedia-based client design can often support UI, data transfer and workflow modifications by altering the server messages rather than altering the client source code. By doing this, it is possible to improve both the user experience and the system functionality without the need for re-submitting the client code for “app store” review and re-deployment. This also has the potential to reduce the need for interrupting a user’s day with download and reinstall events and can, in the process, cut down on the bandwidth costs incurred during the repeated roll outs of code modifications to a potentially large user base.

Improved agility, a better user experience and reduced bandwidth costs are all tangible benefits that are possible when investing in a hypermedia-based implementation for your mobile client application.

December 3rd, 2012

A Break in the Clouds

A Break in the CloudsA recent study by researchers at North Carolina State University and the University of Oregon describes a threat scenario that allows attackers to exploit cloud-based resources for malicious purposes like cracking passwords or launching denial-of-service attacks. The study has gotten a lot of attention, including articles in reputable sources like Dark Reading, Ars Technica and Network World.

In order to optimize the performance of mobile apps or browsers, some computation-heavy functions have been offloaded to cloud-based resources, which in turn access backend resources and Web pages. This creates a middle ground in the cloud that is exploited in the attack, which the authors call “Browser Map Reduce (BMR)”. In reading the paper, it’s clear that this is a legitimate threat. The authors actually carried it out using free resources, although they limited the scope in order not to be abusive.

Aside from questions of curiosity around the mechanics of the vulnerability, the obvious question is this: How can we mitigate this threat? Here are a few perspectives here as well as a method for each.

Apps – This “cloud offload” architecture has arisen because of the processing limitations of mobile devices. When a backend resource is requested by a mobile user, it makes sense to have the data returned in the most consumable format, in order to optimize user experience. Whenever possible, instead of doing this through “browser offload”, data should be returned as JSON objects. This API approach is a proven method that works for mobile devices and is not subject to the BMR threat.

Cloud Services – This threat should not be viewed as a dismissal of the “cloud offload” approach. Cloud-based resources are necessary for handling caching, data indexing and other key functions in the mobile paradigm. However, it serves as a warning that these dedicated cloud-based resources cannot be considered part of a walled garden that includes the associated mobile app. The resource’s entry point must be protected against attackers. Layer 7’s SecureSpan Mobile Access Gateway is an ideal choice for this access control, as it uses identity-based measures to ensure that only requests from legitimate sources are serviced.

Web-Based Resources – Although the backend Web resource was not exploited in this scenario, the study is a reminder that the topology of the mobile Web is changing and increasing in complexity. P2P app-to-API connections cannot be assumed and therefore inbound API calls cannot be implicitly trusted. API access must be controlled and the SecureSpan API Proxy is a leading solution for this purpose.

To sum up, this is a legitimate threat but not a reason to abandon the use of cloud-based resources for mobile app optimization. Be aware of the threats, employ the mitigations and then you can continue to enjoy the exciting growth of the mobile Web.