Web Apps as the new Lingua Franca

I've recently been involved in some conversations around the "lock-in" provided by the mobile system development platforms: once you start working towards (for example) an Android app, it's going to be an Android app. Deploying it on another platform generally means that you have a lot of porting work to do, and multiple codebases to maintain.

I think that's yesterday's model. I think the model for the future is "web apps," by which I mean applications developed using HTML5, JavaScript, and the various APIs coming out of the W3C.

An objection I've heard raised here -- actually, two different objections, but with the same root -- is (1) people don't want to open their web browser and surf to a web page to run their programs, and (2) the mobile web browsing experience is not terribly convenient.

What's critical to realize is that "web apps" aren't necessarily bound to the experience of "opening up a web browser as an explicit action, navigating to an application's web site, and then interacting with it as if it were a web page." Web-apps-as-first-class-apps is a viable model for development and deployment. And there is a team of people inside Mozilla who are working really hard to make this work as seamlessly as possible.

Both FirefoxOS and BlackBerry 10 inherently treat HTML5/JavaScript applications as "first class" apps. In FirefoxOS, it's the sole means of developing applications; and BlackBerry 10 uses it as one of several native development environments. In both cases, the user's experience is indistinguishable from what they're used to apps doing: there isn't even an intermediating browser anywhere in the mix. The HTML5 and JavaScript engines are an inbuilt part of both operating systems.

I recognize that neither platform has the penetration to be a real game changer; at least, not at the moment. I'm holding them up as existence proofs that the approach of "web app as native app" is viable. But let's talk about how these technologies can be leveraged for native webapp deployment on Android, iOS, and Desktop systems.

All of these systems have their own idea of "installed applications." To be successful, we need some way to make these HTML5/JavaScript applications look, act, and feel like every other kind of application (rather than "something running in a web browser").

This is where the work that Mozilla has been doing for web app deployment comes into play, and it's easier to demonstrate than it is to explain. If you have Firefox installed on your desktop (or Firefox Aurora on your Android device), you can go to https://marketplace.firefox.com/, find apps that amuse you, and click on "install." At that point, Firefox takes the steps necessary to put an icon in whatever location you're used to finding your applications. On your Android device, you get an application icon. Under OS X, you get a new application in Launchpad. For Windows, you get... well, whatever your version of Windows uses to access installed apps.

From that point forward, the distinction between these web apps and native applications is impossible for users to discern.

Interestingly, iOS was both a bit of a pioneer in this space, and also remains the most frustrating platform in this regard. If you recall Apple's stance when the original iPhone first launched, they didn't allow third-party applications at all. Instead, their story was that HTML and JavaScript were powerful enough to develop whatever applications people want to write. Presumably as part of this legacy, iOS still allows users to manually save "bookmarks" to their desktop. If the content behind those bookmarks is iOS-aware, then the bookmarks open in a way that hides the browser controls -- effectively acting like a native app. If you have an iOS device, you can play around with how compelling this experience can be by going to http://slashdot.org/ -- select the box-and-arrow icon at the bottom of your browser, and click "Add to Home Screen." Now, whenever you open the newly-created icon, it acts and feels exactly like you downloaded and installed a native "Slashdot" application onto your device. It even appears in the task management bar as a separate application.

The reason the iOS experience remains frustrating is twofold. First, and primarily an annoyance to developers: the only HTML5/JavaScript rendering engine allowed on the platform is Apple's own webkit implementation. This frustrates the ability to add new APIs, such as may be required for new applications. So, new APIs are only added at whatever pace Apple's product plan gets them added. Secondly -- and of actual concern to users -- there is no programmatic way to add web app icons to the desktop. Creating these icons requires a relatively arcane series of user steps (described above). Basically, Apple is playing the role of the napping hare in this tortoise-and-hare race: they were very fast out the gate, but have been asleep for quite a while now.

But that covers all the bases: it's possible to develop HTML5/JavaScript apps that truly run cross-platform for iOS, Android, Blackberry, FirefoxOS, and a variety of desktop systems -- even if the Apple experience is somewhat less than satisfying (for both developers and users).

I suspect most of what's holding developers back is predominantly a lack of knowledge that this is a viable technical model. I've heard developer feedback that one major reason they aren't targeting JavaScript environments involve concerns about the speed of execution in a JavaScript environment. It's not yet clear whether these problems are merely perception or reality.  I've seen some impressive things like usable cryptography, high-def video codec decoding, and high-performance first-person 3D environments (including viable multiplayer first-person shooters) implemented in pure JavaScript, so I suspect it's more a perception problem based on very outdated experiences. I'd love feedback from anyone who has run into performance problems trying to use this model with a modern JavaScript interpreter.

It's official: No SDES in the browsers.

I wanted to follow up on my earlier post regarding WebRTC security. In that post, I mentioned that RTCWEB was contemplating what role, if any, SDES would play in the overall specification.

At yesterday's RTCWEB meeting, we concluded what had been a rather protracted discussion on this topic, with a wide variety of technical heavy hitters coming into express opinions on the topic. The result, as recorded in the working group minutes, is:

Question: Do we think the spec should say MUST implement SDES,
MAY implement SDES, or MUST NOT implement SDES. (Current doc
says MUST do dtls-srtp)

Substantially more support for MUST NOT than MAY or MUST

**** Consensus: MUST NOT implement SDES in the browser.

So, what does this mean? The short version is that we just avoided a very real threat to WebRTC's security model.

I'd like to put a finer point on that. There was a lot of analysis during the conversation around the difference in difficulty of mounting an active attack versus a passive attack, the ability to detect and audit possible interception, and a variety of other topics that would each require their own article (although I think Eric Rescorla's slides from that session do a good job of summarizing the issues rather concisely). Rather than go into that level of detail, I want to share a brilliant layman's description of SDES by way of an anecdote.

One of the RTCWEB working group participants brought along a companion to Berlin for this weeks' meeting. She sat in on the RTCWEB encryption discussion. When she asked what the lively conversation was all about, the working group participant directed her to the relevant portions of the SDES RFC.

Yesterday evening, when we were talking about the day's events, she summarized her impression of SDES based on this lay reading: "It's like having the most state-of-the-art safe in the world, putting all of your gold inside, and then writing the access code on the outside."