Mozilla at Mobile World Congress 2012

March 5, 2012 By Anant in Conferences, Fun, Mozilla, Places, Technology 4 Comments

The Mobile World Congress at Barcelona this year was the first trade show that Mozilla has participated in. This is new territory for us, but given that 2012 marks the year where mobile devices will far outnumber desktops & laptops, it was clear that Mozilla has to play a central role in promoting an open ecosystem for mobile devices. However, we’re a small, community-driven software company, so putting on a professional face at a trade show like MWC to tell the world that we’re serious about our enacting our mission in the mobile space can be very intimidating. Especially when you’re sharing the floor with established industry giants; Huawei, for example, had a whole city block reserved for their “booth”. Other carriers, OEMs, and hardware manufacturers had an equally large presence at the show. At the beginning of the week, what we mostly hoped for was to sneak in, show our wares and gauge interest. What we actually got exceeded our wildest expectations.

We setup our booth at App Planet to showcase many of our products that are relevant to the mobile space: Boot 2 Gecko, Firefox on Android, the Mozilla Marketplace, and Mozilla Persona. There was a continuous stream of people, on all four days, interested in checking out demos of our various products, which meant non-stop talking for booth staff! One of the things we’re really proud of is that our booth was manned by Mozilla staff who directly work on the very same products we were show-casing. This made for some very authentic demos, and we left no question unanswered.

Boot 2 Gecko

On the first day, we made an announcement that we would be partnering with Telefónica to release an open web device, a phone based fully on HTML5, powered by Boot 2 Gecko. This really resonated with almost everyone at the event, and set the tone for the following week. I had several people come up to me at our (rather modest, what I thought would be almost unfindable) booth and ask for a B2G demo, which kicked ass (and was only finished on Sunday night, most of us only saw the working phone on the first day of the show!). One gentleman from the press even commented that it was the only news worth writing about.

This is the kind of response that really energizes the entire team and validates a lot of our thinking in the mobile space. In a world that is dominated and controlled by vertical silos like those built around iOS and Android, our call for a more open eco-system is something that many at MWC were able to understand as being important, and potentially disruptive. Imagine being able to install apps from not just one marketplace, but several, or even just being able to navigate to a web page to install an app, without a gatekeeper or a middleman.

Everyone (including myself) was blown away with the performance of B2G on the demo phones, running apps like Cut the Rope (which was recently ported to HTML, CSS & JS, thanks to Microsoft) just as smoothly as the native counterpart. Our demo had a little view source button, which you could press when you were on the home screen, the dialer app, or anywhere else; and it always put a smile on the audience’s face. This is really a phone made of the web, for the web.

Mozilla Marketplace

The natural transition from the B2G demo happens when someone asks “how do users get apps on the phone?”. Mozilla is going to be running a marketplace for apps written using HTML5 technologies. Our marketplace is already open for developer submissions, and we hope to have a consumer beta ready sometime by the end of Q2 this year.

We showcased some of our awesome partner apps that have already been submitted to the marketplace, running on a variety of different platforms: Android phones, tablets; Mac and Windows computers.

We’re going to have an awesome, community-driven app store (built on the same principles, and even the same code-base as our add-on marketplace), but it will by no means be the only HTML5 app store in town. We encourage, and even support, other companies wanting to setup their own stores; and developers are always free to self-publish apps on their own websites (adding an ‘install’ button to your website is really simple!). We’re going to be supporting paid apps on our marketplace, and also provide an in-app purchase API (credit cards supported via PayPal, and we’re also trying to support carrier billing in some countries); but because apps are built using the same web technologies used for building websites, developers are always free to setup their own payment systems.

It’s a really open eco-system, bringing the flexibility and distributed nature of the web to the app world. If you’re interested in the technical details of how this all works, I wrote a post sometime ago explaining it all. A very common question I received was “is there an SDK I can use?”, or “are there standard UI widgets we’re expected to use?”. The answer is that, this is not just another app store, developers will use the same technologies as they do today to build websites, with a few tweaks here and there (to support multiple screen sizes, and to support offline usage, etc.) to make an app. You can use any of your favorite JS frameworks, UI widgets and server side frameworks to build an app. Again, an app marketplace made of the web, for the web.

Firefox on Android

We also had lots of visitors to our booth who were either fans of Firefox and just wanted to say thanks (we love you all!) or were former Firefox users who now use a different browser (we love you too!).

The original version for Firefox on Android was built using the same front-end code (XUL) as on the desktop and had some performance problems. We’ve since re-written the entire UI to be much more smoother, and really focused on improving startup speed. We had some amazing demos of Firefox on Android phones and tablets that showcased all of these improvements, and more.

We also had a chance to demo some of the cool new WebAPIs that we’ve introduced (many of them driven by the needs of B2G!): such as camera access, accelerometer, vibration, etc. I think most of our visitors were very pleased with how far Firefox on mobile has come, with competitive performance and a smooth browsing experience. We look forward to pushing the latest nightly version into the Google Market on Android as soon as possible so everyone can get their hands on them! (If you’re an impatient daredevil, just head to the nightly page to download the latest & greatest).

That’s not all

Mozilla Persona came up a lot in conversations, as identity is the binding glue for all our projects. Enabling a really simple sign-in process on not just websites but also devices like B2G phones; while respecting user privacy and choice, is a high priority for us. We were able to do demos of a Persona based login to the Apps marketplace but also explain to everyone interested about how this is not just another login system like Facebook Connect, but rather a federated and distributed system for identity. Keep up with the latest developments in this space on the Mozilla Identity blog!

During the same week as MWC, Gary announced Collusion at TED U, an add-on that lets you discover who’s tracking you online. With the recent debate around user privacy, especially in the mobile space, it wasn’t surprising that there were quite a few people who were interested in Collusion at MWC. I was able to give a few demos of the add-on in action on the desktop computers, but unfortunately we didn’t have a version working on our Mobile browsers (something we hope to fix in the near future). It was awesome to be able to demo this at MWC and show to the world that user privacy comes foremost at Mozilla (Firefox was also the first browser to implement Do Not Track).

All in all, this past week has been pretty exciting for all of us. Firefox brought openness to the web almost a decade ago and played a key role in shaping the web to where it is today. However, as the world is changing and becoming more mobile, we’d like to bring the same values and principles with us into this new realm. At MWC, we showed the world that Mozilla is a serious player in the mobile space. We made a lot of promises, and we loved the response; now is the time to execute. I hope that at the next mobile world congress, we will have lived up to all our promises and have a pretty compelling demonstration of what we accomplished in 2012.

The web is the platform. And Mozilla is leading the charge. Onward!

PIPA/SOPA: Not good for anybody’s health

January 17, 2012 By Anant in Mozilla, Technology Leave a comment

Wikipedia, Google, Reddit and several other major sites are protesting the PIPA/SOPA legislation by either completely blacking out their sites or by modifying their front pages to inform their visitors of this harmful legislation that the MPAA is trying get the U.S. Congress to pass. I’m proud that Mozilla will be also be participating in the ‘internet strike’ tomorrow!

I’ve rarely discussed politics on my blog, and as an Indian citizen I am particularly helpless to do anything about U.S. legislation. Mitchell and many others have already posted level-headed arguments on why PIPA/SOPA isn’t going to help anyone. However, this response from the MPAA’s chief executive Chris Dodd (who is, notably, a former US Senator) really irks me:

Only days after the White House and chief sponsors of the legislation responded to the major concern expressed by opponents and then called for all parties to work cooperatively together, some technology business interests are resorting to stunts that punish their users or turn them into their corporate pawns, rather than coming to the table to find solutions to a problem that all now seem to agree is very real and damaging.

It is an irresponsible response and a disservice to people who rely on them for information and use their services. It is also an abuse of power given the freedoms these companies enjoy in the marketplace today. It’s a dangerous and troubling development when the platforms that serve as gateways to information intentionally skew the facts to incite their users in order to further their corporate interests.

A so-called “blackout” is yet another gimmick, albeit a dangerous one, designed to punish elected and administration officials who are working diligently to protect American jobs from foreign criminals. It is our hope that the White House and the Congress will call on those who intend to stage this “blackout” to stop the hyperbole and PR stunts and engage in meaningful efforts to combat piracy.

The MPAA has, in the past, used its “power” to enact legislation that makes it illegal to manufacture DVD players that allow lawful, paying consumers to skip the FBI warning shown at the beginning of DVDs. The MPAA is now using that very same “power” and political clout to enact PIPA/SOPA. It is plainly hypocritical that the MPAA would call Google and Wikipedia irresponsible for displaying accurate information on their own websites.

Furthermore, the MPAA calls out for “co-operation” from technology companies on the matter of piracy. I am at a loss to understand why Google or any other technology company should spend even a cent of their hard-earned money on solving a problem for the MPAA. Why didn’t the MPAA use its enormous cash pile on technology that would enable them to profit from evolving technology instead of spending it all on lobbying a bill that threatens the Internet’s very existence?

The retort from the MPAA is that they’re not against the Internet, just piracy. However, that’s exactly where the problem lies. The PIPA/SOPA bills as currently drafted would give the MPAA (a private entity, mind you) the overarching power to shut down any website, without legal recourse, all in the name of combating piracy. Even if I trust the executives at the MPAA to not abuse that power, I do not fool myself into thinking that there will be no mistakes at all. Taking down a website for no real legal reason, even temporarily, is just not worth it – especially when the end goal is to let the MPAA make an extra million dollars.

Thankfully, the Internet is not designed to let any single entity obtain that much power (one could note that it is that distributed nature of the Internet that makes it so successful). Even if the bill is enacted, it will not prevent people from being able to reach these “rogue” websites that publish pirated content. Consumers will still be able to reach websites not hosted in the U.S. (as most of them are) via their direct IP address, and site owners can always be a step ahead by registering new domain names if they choose to. Not to mention, the Streisand Effect is likely to swing into action, further fueling the trend of people visiting rogue websites for pirated content. For example, it is trivial to write an add-on for Firefox and other browsers that would bypass the DNS “blacklisting” technique PIPA and SOPA propose to implement. There is no way that the MPAA, the U.S. Government, or any single entity for that matter, can stay on top of thousands of such work-arounds.

The technology companies and architects of the internet have openly informed the MPAA about the fallacies of the bill (something that they couldn’t figure out for themselves); for the MPAA to expect any more “co-operation” from them is futile.

Nobody in their right mind has ever said that piracy is not a problem. However, the benefits that the Internet brings to humanity is far too much to let a private corporation endanger it just so it can continue to profit. In the long run, for any corporation to stay in business, it must adapt to evolving technology. Digital goods are just not the same as physical objects, bits have no colour. The companies that realize this fundamental, unchangeable truth and try to capitalize on technology are the ones who will ultimately succeed, not the ones who try to fight it. In the physical realm, we don’t outlaw things that brings a lot more good to society even if you are able to do a few bad things with it (though increasingly governments seem to punish the masses in the name of fighting a few bad apples; which is also no doubt a very troubling phenomenon). I hope the MPAA will use its power and money to figure out how it can profit from technology in a way that preserves the founding principles of the internet, for its own sake, or it won’t be too long before someone who does replaces them.

Behind the Mozilla Apps Developer Preview

December 15, 2011 By Anant in FOSS, Mozilla, Programming, Technology 5 Comments

On Tuesday, we launched a developer preview of the Mozilla Apps project, something I’ve been working on for the better part of the year. We released a suite of tools and documentation aimed at helping developers write, deploy and sell apps built using modern web technologies like HTML5, CSS and JavaScript. Many others have already covered the question of “why” we are doing this: all the major app ecosystems out there are closed, tied to a single vendor, and could certainly use a healthy dose of the openness. There are many great things about Apps, and many great things about the Web, and we want to bring them together. [UPDATE: Tim Berners-Lee agrees!]

In this post, I want to cover the “how”. If you’re interested in writing apps, I would point you to the documentation we have on how to build them. On the other hand, if you’re curious to learn about how the system works as a whole, read on! A lot of different pieces of technology had to come together to get where we are today.

App Manifest

A fundamental building block of the system is the app manifest. Every app in the system is represented by this JSON file, documented here, which essentially contains a set of metadata about your app: name, icons, localized descriptions and so on. This manifest file is hosted at the same domain as your app. An app is uniquely identified by the domain it is hosted at, and this manifest must be served off the very same domain (at any path), with the Content-Type header set to application/x-web-app-manifest+json. We’ve received a lot of feedback stating that this is limiting, but unfortunately almost every security knob in browsers is tuned to the domain of a given page. Because we anticipate that apps will, at some point, be able to request access to elevated privileges (to use the computer’s web camera, for example), we must restrict ourselves to one app per domain. Note that app1.example.org and app2.example.org are different domains but example.org/app1 and example.org/app2 are not.

There are many other specifications that express ideas similar to this concept of a manifest (W3C Widgets, Chrome Web Store, etc.), and we are definitely very keen to standardize the format.

API: mozApps

The next piece we introduce are a set of new DOM APIs, present under the navigator namespace. The API offers a few different functions, but the most important one is navigator.mozApps.install. This function allows a web page to initiate the “installation” process for an app, which is identified by the URL to its manifest (explained previously). Any page is able to invoke this function, so you can self-publish your apps! Just add an “Install” button to your site and call this function with the right arguments. The API also provides a function that can tell if your app is currently installed (amInstalled).

There is another set of APIs under the navigator.mozApps.mgmt namespace. These “management” functions are only available to certain privileged domains, and are able to query the DOM for a list of all apps the user has installed, launch any given one, and uninstall an app. This API is expected to be used only by web pages that the user has explicitly authorized as being able to manage their apps on their behalf. We call such web pages “Dashboards”, and we built a default one into the system (which I shall explain shortly).

The mozApps API is fully documented, but you should note that as with any early DOM API (that we hope to standardize), it is subject to change. In fact, we’re already thinking about how we can further simplify the API and make it more standards-friendly. Join the discussion!

HTML5 App Runtime

Now, what actually happens when somebody calls a function described in the mozApps API? We’d like for users to be able to look for, install and launch apps from any standards-compliant browser without having to do anything special. So, we’ve built a fully in-content implementation of the mozApps API, provided by include.js that is served off the myapps.mozillalabs.com domain (the reason for that will become apparent when we discuss dashboards). Just include that JS file in any page that uses the mozApps API and you should be good to go! This applies to self-published apps as well as stores.

Now, whenever the install method from the mozApps API is invoked, the user is greeted with a dialog asking them to confirm if they’d like to install the app:

The Dashboard

Let’s say the user confirms the installation, what next? After a set of sanity checks against the manifest of the app, it is officially installed into the users collection of apps, which we call a repo. A Dashboard is the piece of software that is responsible for letting the user manage their repo, by allowing them to launch and uninstall their apps. Recall that the mozApps.mgmt set of APIs allow a dashboard to do this, and currently the myapps.mozillalabs.com domain is white-listed. In the future we expect people to write dashboards (which is essentially an app to manage apps!) that users can authorize. When a user visits the default Mozilla Labs dashboard, they look at something like this:

We implemented a touch friendly dashboard that works on both mobile devices and the desktop, to let you re-arrange your app icons and organize them in pages. This part of the dashboard is implemented using the wonderful icongrid library, which you are more than welcome to re-use while writing your own dashboard!

Clicking on an icon will launch that app. What does launching mean? In the HTML5 app runtime, it means it will open up the app in a new browser tab. However, we’ve also been experimenting with how we can improve this experience, which we will discuss next.

App Runtime for Firefox

For Firefox users, we have the opportunity to provide enhancements to the whole app installation and launch process while we wait for the API to get standardized. We’ve written an add-on that implements the mozApps API, which will override the include.js HTML5 runtime version (so stores are encouraged to continue including the include.js version to provide the most portable experience for their users). If you have this add-on installed and install an app from any page or store, you will be greeted with a doorhanger that asks you confirm if you really intend to install this app:

Note that there’s an extra option in there that asks if you want to install the “native” app version or not. On Windows and Mac, this means that we will automatically generate a .EXE or .APP that wraps your web application into a shell that looks and feels like a real app! For example, on the Mac, we will create a menu bar and dock icon for you:

Cool? Sounds pretty familiar to the Prism experiment, right?

In addition to this style of “native” launching, users can also use the dashboard from before as usual. Launching from the dashboard will open it in an app tab, a nifty little Firefox feature.

App Runtime for Android

An important feature of Apps written using web technologies is that they can work on a variety of different devices. We want users to be able to buy an app only once and use it not only on their desktop, but also on their tablets and phones. We’re going to start out with Android (iOS has its own set of tricky technical and policy problems to deal with), by introducing an App Runtime (codename “Soup”).

The App Runtime for Android is a native Android application that lets users install, launch and manage their apps just like on the desktop:

Installing an app on Android using Soup will create an icon in your home screen, tapping on it will launch the app using our embedded web runtime. Well built web applications can now look and feel just like native android apps!

In addition, apps that you installed on the desktop can be automatically synchronized to your phone (and all your other devices) using our Sync functionality, which we will discuss next.

Sync

Users shouldn’t have to install apps on every device they own once they’ve purchased it. We’ve developed an AppSync solution for the HTML5 runtime, Firefox runtime as well as Android. In all three environments, you should be prompted to login with your BrowserID (Mozilla’s new federated & distributed Identity system) when you visit the dashboard:

Once you’ve logged into your dashboard, your apps from all your devices should start automatically synchronizing!

App Marketplace

Search is a great tool for the web, and we expect that many users will discover apps using search engines. However, directories have their place and are an invaluable tool to create a community around apps. Mozilla has been running addons.mozilla.org (AMO) for a while now, an easy place to find, install and review add-ons for Firefox. We want to build a similar store for Apps, and as part of the developer preview, we launched apps-preview.mozilla.org. This preview of our “app store” lets developers submit an app by telling us the link to their manifest (the process is very similar to how you submit an add-on for inclusion on AMO). Once the application is accepted into the store users can find, install, review and provide ratings for apps. This store uses the same mozApps install APIs we discussed earlier, and we expect that others will build their own stores. We want competition in the app store market too!

Supporting developers who want to sell apps is also important to us. We’re testing integration with Paypal as part of the developer preview, which will allow developers to sell apps across the world at various price tiers.

Receipts

How do we balance the need for developers to be able to charge for their apps, while allowing users to use an app they’ve already paid for across all their compatible devices? We’ve devised a receipt format that helps achieve this. When a user completes the payment process on a given store, the store will generate a receipt of this format and pass it to the mozApps API as part of the install data provided to the install call. The implementation responsible for providing the API will stash the receipt along with the app itself (and all devices the app is synced to).

At launch time, the app can ask for the receipt associated with itself using the amInstalled API call, do an integrity check, and send it over the original store that issued the receipt. The store can then verify that the receipt is indeed valid and notify the app, at which point the app can decide whether to let the user run it or not. We’ve provided a utility function verifyReceipt to help the app developer do all of this.

Do note, however, that this whole scheme is merely intended to help developers who don’t want to setup their own payment systems. Developers are free to write apps that use their own (or 3rd party) payment or subscription services. You could, for example, sell your app for free on the AMO store, but ask users to login when the app is launched, or implement your own in-app purchasing system. We will do what we can to help, but in the end, you’re in full control of what your users see when they launch your apps!

What’s next?

This is just the beginning, we have a lot more work to do before we can realize a flourishing and open app ecosystem for the web. Here are just some of thing we have planned for the next few months:

Building out a “Web Runtime”, or WebRT. We’ve built an initial prototype of how such a runtime might work in the add-on for Firefox, and we want this to extend this to a more robust system with auto-updates and deeper OS integration.
Capabilities. In conjunction with the WebAPI project, we want to provide apps with more device APIs and capabilities than regular web pages, while giving the user an easy way to control and hand out permissions. This includes things like camera access, filesystem APIs and more.
Web Activities. A while ago we release a prototype of the apps extension that supported what we call web activities, a way for apps to communicate with each other safely and easily. You could use this, for example, to upload a picture to a site from your favorite photo service, or to share a link from an app to all your friends using your favorite social network. The Firefox Share add-on already relies on web activities to do the latter.
Push sync & notifications. We want users to be able to “push” apps to any of their devices directly from an app store.
Standardization. It is critical for the health of the web for all of these app related APIs to be standardized and supported by all interested parties.

Most importantly, we want you to get involved and help us build!

Show me the code

I’ll end this post with a brief description of all the code behind the various pieces in hopes of attracting contributors All of our code is hosted on Github and licensed under the MPL/GPL/LGPL tri-license.

The main repository for the Apps project can be found here. It contains the source code for the HTML5 App Runtime (include.js and trusted.js are the important pieces), the App Runtime for Firefox and the Dashboard that is currently deployed on myapps.mozillalabs.com. The Dashbaord was built using IconGrid, a JavaScript library to build touch friendly scrollable pages. The App Runtime for Firefox is written using the Add-on SDK and shares a few common files with the HTML5 runtime (repo.js, urlparse.js, manifest.js and sync.js).

Source code for the Android App Runtime (codenamed ‘Soup’) can be found here. It is a regular Android application written in Java with an embedded PhoneGap instance to support the marketplace and app launching.

On the server side of things, Zamboni is the code that powers addons.mozilla.org, and was extended to support apps-preview.mozilla.org. It is built on Django. The AppSync server is also written in Python (using Cornice) and is what powers app synchronization across all three runtimes (HTML5, Firefox and Android). The AppSync server in turn talks to Sauropod, written in node.js and backed by HBase. Sauropod is a Mozilla Labs experiment aimed at building a secure storage system for user data. Tarek Ziadé has a more comprehensive overview of how all the server side pieces fit together, which you should go read!

Don’t hesitate to participate and ask questions on our mailing list. We encourage you to play around with the system and file any bugs that you may find here. Together, we can make an open, healthy app ecosystem for the web a reality. We look forward to hearing from you!

11/11/11

November 11, 2011 By Anant in Uncategorized Leave a comment

Given I haven’t updated my blog in a while, I thought I’d take this rare opportunity to chronicle a special, once-in-a-century repunit palindrome day.

Folks in 2111 will have us beat though with two consecutive palindrome days, 11/11/11 and 11/12/2111!

Why should you encrypt user data?

August 2, 2011 By Anant in Mozilla, Technology 7 Comments

One of the things I like most about Firefox Sync is that all my browsing data is encrypted before anything leaves my computer. This wasn’t easy to do, there is a ton of engineering effort involved in scaling servers, maintaining all the crypto code for the client, and most of all, in making the experience smooth and inclusive of all types of users. The last one is especially hard since average users find it hard to grok the concept of two passwords (one that the server knows and another that only they know, which means if they lose or forget the latter we really can’t help them). I can’t think of any major services out there that offer the same feature (it is clear now that Dropbox does not encrypt user data in an irrecoverable manner EDIT: Peter points out in the comments that Chrome does allow you to encrypt your passwords), and for good reason: it is damn hard to pull off. All the more reason to be very proud of the Mozilla Services team.

The question of why we should bother doing all this has come up now and then. Users readily trust a lot of services with their personal data. Google could read your email if they wanted to, but they have a reputation to maintain and therefore have strict internal policies on who has access to what. Every other service that allows access to your data via a web interface operates in the same way. Surely, Mozilla is just as trustworthy, (if not more) than all of them. Why not get rid of client-side encryption to make the user experience really awesome and save many valuable hours of engineering and operations effort?

Additionally, if programs on the server-side (not humans) had access to unencrypted browser data, there are many more interesting services one could offer. If these services are compelling enough, until homomorphic encryption becomes usable commercially, they are a good argument for why you may not want to encrypt user data in a way that not even the server can read it. However, doing this also has some drawbacks…

between PSN and Dropbox, lots of reminders about why Firefox Sync feels like the solution we want to provide
—
Mike Connor (@mconnor) April 27, 2011

Running production-quality servers is no walk in the park. There are so many ways in which a small misconfiguration can open up your service to all sorts of attacks. But what makes it even harder is a 0-day exploit in the web/application server you happen to be using, because then you have to wait for upstream to fix it. And then you have to make a judgement call, do you take your service down until a fix is released? Many would blame Sony’s technical “incompetence” for the PSN data leaks, but the fact remains that servers are run by humans, and humans make mistakes.

Keeping the user’s data encrypted provides everyone with an extra layer of protection. Not from the folks running the service, users probably already trust them, but from everyone else. And that doesn’t just include groups like Lulzsec or Anonymous.

Unfortunately, whether we like it or not, it is ridiculously easy for the government to strong-arm a technology company (especially one that isn’t giant enough to generate press) into releasing data for individuals, even for frivolous reasons. There has certainly been a lot of precedent for these kinds of “requests” from the government, and not all companies (Twitter, most famously) respond to them with user data, but that is harder to do for companies that don’t have that much money to spend on lawyers. In the real world, there are laws that require the government to obtain a search warrant before they are able to gain access to your physical belongings, and until we have the equivalent of a search warrant for an individual’s digital data; encryption provides a fine compromise.

If you can make your application work entirely client-side, using the cloud merely as a storage mechanism, you should. It’s worth the extra week you put into working out the crypto. JS is rapidly becoming fast enough to do a lot client-side, and with things like DOMCrypt, this realm is poised to get better with time.

Apps

March 4, 2011 By Anant in FOSS, Mozilla, Technology Leave a comment

The word of the year in 2010 was “app”. Everyone is talking about it now, but both you and me have been using apps ever since we first used a personal computer. What has changed is the prevalence of mobile devices that are particularly good at doing at one thing at a time. The desktop computer (or laptop) on the other hand, has evolved from being able to do only one thing at a time to the multitasking beast it is today. Yet, the fact remains that as humans we can’t really multitask, though we can fake it by doing really fast context switching (just like a computer!). I think this is the main reason behind why apps are so successful on mobile devices.

Apple, as usual, knocked it out of the park with their mobile app store. And since then we’ve seen a landslide of app stores open up on several different platforms with varying degrees of success. Linux has had ‘package managers’ for more than a decade, there are even some with fancy GUI front-ends that many consider to be an app store. But they lack the (semi-)curated nature of Apple’s store, and not to mention shiny icons. Users like the shiny stuff. No doubt, apps are here to stay.

The role of Statefulness

As a result, we’ve been thinking a lot about how this model translates to the web. It used to be that the web was just a very large collection of (mostly) static pages. Large parts of the web still are (eg. Wikipedia), but we also observe another breed of content on the web that is highly personalized (eg. Facebook). This changes the nature of something fundamental about the web, and what a hyperlink means. A decade ago, when you linked to a web page you expected the recipient to see more or less what you saw; but today that may not be true. In many cases the recipient will experience a ‘personalized’ version of the same content, and in cases like Gmail, hyperlinks don’t even make sense because the entire website is for your consumption only.

The web is now more stateful than ever (even though the underlying protocols haven’t changed to reflect this – but that is a topic for another blog post) and I think web apps are a great way to capture the essence of such stateful websites. I certainly recognize that traditional web pages aren’t going anywhere; but that the web has simply evolved to serve several different use-cases. There are times when all I want to do is just read an article, watch a video or post an anonymous comment (haven’t we all done that!). But, a lot of the time I am using the web in a very personal way and apps are a great way for me encapsulate that activity.

Open Web Applications

Today, we made an integration release of the Open Web Applications project; which, in its most basic form, is a culmination of our answer to the question: “What is a open web app?”. We define the term as applications that run on any device, and can be distributed through any store or directly by the developer. But that is just the tip of the iceberg — formulating a way for web applications to present themselves to the user agent is just the first step. Here are a few ideas on what we think might have great impact on the ways in which users interact with web content:

Dynamic service discovery: Web applications should be able register themselves with the browser as being able to provide one or more services, which, after authorization by the user, could be used by another web application. In this scheme, the browser plays the role of the mediator between two web applications and the user; providing a greater level of flexibility and modularity in the flow of user data than the web has ever seen. Mike Hanson has discussed this idea in detail before, and you should read that blog post to understand the why and the how.
Deeper OS integration: HTML, JavaScript and CSS have proven to be versatile technologies that so many developers have been using to do amazing things with. There is no reason for these technologies to not be the preferred choice for application developers to bring content to users on a variety of platforms, both on desktop and mobile. Web applications are poised to be treated as first class applications by operating systems. The ability to register Pandora as my default music player and use keyboard shortcuts as usual to control it even while it is in the background is something I really want. Dare I say that this is the return of ‘write once, run everywhere’? The UI concept gallery from the integration release discusses some of these aspects.
Wherever you go, the web follows: Firefox Sync allows you to carry your browser data with you, but we can extend this even further by synchronizing application state. The web application framework provides a great way for developers to specify what the best user experience for someone using their application across multiple devices in succession should be. This reminds me of the old Hutch ads (a mobile network in India, now Vodafone); where the web is your metaphorical pug that follows you wherever you go

These are just some of the ideas that we’ve come up with so far, and I am sure there are many possibilities we haven’t even thought of yet. If you are considering writing an application and are targeting multiple environments (say, Mac, Windows, Linux, the iOS and Android based devices), we think web technologies make a very compelling choice. We would love to know what Mozilla can do make the ‘app experience’ much richer for both users and developers!

Binary Sunrise

Anant Narayanan

Author Archives: