When I joined Mozilla, it was very hard for me to envision any better job than the one I had. In fact, I still think that’s true, but when I met and spoke with the folks from Firebase, I knew I had found another job that could be just as good! The team is small (7 including me), consists of really intelligent and likeable people, all of whom are engineers, and they’re working in a space I have a deep academic and professional interest in.

But why a startup? In the words of Cobb, from Inception:

What is the most resilient parasite? Bacteria? A virus? An intestinal worm? An idea. Resilient… highly contagious. Once an idea has taken hold of the brain it’s almost impossible to eradicate. An idea that is fully formed – fully understood – that sticks; right in there somewhere.

And somewhere along the way, the thought of what it would be like to work at a startup entered my head. Maybe it was the near constant buzz about startups around me, or my daily reading of hacker news. Maybe Cobb and crew planted the idea when I was unconscious on a plane. I don’t know. But there it was…

I normally ignore emails from recruiters, since most of them are poorly written and ill-researched (my friends have had similar experiences), but this particular email was well crafted and it had to do with start-ups. I was already pretty curious, and finding out more couldn’t hurt, right? Here we are!

I’m really looking forward to this roller-coaster ride, as one of the founders put it. In addition to writing code, which I love, I’ve also always enjoyed talking to others about my work. At Firebase, I’m going to be doing a bit of both, so you’ll most certainly hear more about my adventures as they unfold.

Wish me luck!

Almost 5 years ago at FOSS.IN, I met a group of friendly folks, who despite having to endure the effects of an extremely long journey into a crowded city with less-than-ideal weather, patiently explained how the one-of-a-kind world of Mozilla worked. I had no idea what kind of impact those few days would have on my life, or that it would lead to a rewarding career writing open source software. In fact, it still boggles my mind when I think about the series of fortunate events that had to transpire to bring me where I am today.

A lot of things had to happen for my first patch to be committed. Myk spent hours teaching me how to build mozilla-central, taught me how to make a patch and put it on a bug, and explained how the review process worked. Of course, I was a total n00b back then, but I was also extremely lucky to have bz review my patch. As you can see on the bug, bz is the epitome of patience and kindness.

I got very lucky again a few months later, when I interviewed for an internship at Mozilla, and despite my (in my view) somewhat mediocre performance during the phone screen, Mozilla decided to take a chance on me anyway!

I spent the summer working on Weave with Dan Mills and the rest of the Labs crew, and made my first significant contribution in terms of code to Mozilla. At the time Labs was led by the amazing Chris Beard, and consisted of Atul Varma, Jono Xia (his last name was still DiCarlo back then!) and Aza Raskin, who had all arrived from Humanized earlier that year, and Myk. Dan was instrumental in moulding me from an amateur enthusiast into a professional programmer. It wasn’t until the end of that summer that I really believed I could write code for a living. I owe much of my life today to Chris, Dan and Myk. I had a blast that summer with the most awesome group of interns, and left determined to come back and be a Mozillian for life.

I could go on and on about all my Mozilla memories (the two summits in Whistler, the numerous all-hands, office pranks, nerf ball wars, trip to Las Vegas, …) and all the cool projects I got to work on (Firefox Home, Jetpack, Rainbow, Apps, WebRTC…) but the gist of it is that my life has completely revolved around Mozilla for the last 4 years, and has fundamentally changed me as a person. I think it is very rare to find such a high concentration of splendid folks who are passionate, crazy smart, and have a sense of humour in one place.

The highlight of my stay at Mozilla has definitely been the fantastic opportunity to work with some amazing people. Authors of the very same books I read as a student, people whose technical prowess leaves me in awe, folks who wrote the software I use on a daily basis, people who invented technology in use by billions, people who have taught me more in a few months than all my previous teachers put together, and people who I could only dream I’d meet some day, let alone work with. That wasn’t all – I had the chance to work with so many unsung heroes – hardworking, humble and brilliant people who day-after-day managed to amaze me with their awesome splendid nature.

But I didn’t just have the chance to work with amazing Mozillians. Being a part of the organization also gave me the opportunity to meet other people with similar qualities from around the world. Through work with standards bodies like the W3C and IETF, and community events like MozCamp, I had the chance to visit various parts of the world to soak in different cultures and ideas. I learned so much about life, food, love, etiquette, physics and everything else worth knowing, just by being a part of the community.

And so, even though it is cliché, it could not be truer that the decision to leave Mozilla has been one of the hardest in my life. Thankfully, I will always be a Mozillian, which I think is the best perk of being part of an open, community-oriented organization. John Lilly (who I had the fortune to meet, again, thanks to Mozilla) has written about how a person’s first few years in their career goes on to define how they approach problems much later in life. I couldn’t be prouder or happier that my first job has been with Mozilla. A very high bar has been set, and there is no doubt that I will continue to carry their watermark with me wherever I go.

Thanks Mozilla, for the best 4 years yet.

As for what’s next, more soon!

The theme of the weekend was Mobilize Mozilla, which to me meant rallying the Mozilla community around our various mobile efforts which includes Firefox for Android and FirefoxOS. For years, Firefox on Desktop has been and still remains Mozilla’s flagship product, but there was never a doubt that Mozilla’s mission was much larger than Firefox. The opening keynote was by Tristan and Mitchell, which covered some general updates on various Mozilla activities around the world and specifically Europe, but also some inspiring comments on why our priorities at Mozilla are the way they are. I especially liked Mitchell’s emphasis on building quality products that people love to use. As Mozillians, we’re clear on what our values are, but no piece of software can perfectly represent them. Even Firefox isn’t perfect, which is why we’re improving the security and privacy it can offer with every release. What matters is that we’re taking small steps, each one bringing us closer to the “perfect product”. Now that we’re building mobile products, we’re going to be challenged with some decisions that may be hard to make. In times like this, it’s important to keep the big picture in mind; Mozilla can’t do any good if it becomes obsolete!

The second keynote was by Jay Sullivan, who gave us an overview of where we are with all our products currently, and what’s coming up in the future. There were some pretty cool demos as well, and I had the wonderful opportunity to showcase BananaBread, a 3D FPS built by azakai and several other Mozillians, using only HTML5 – no plug-ins. It uses emscripten to convert the open source Cube2 game engine “Sauerbraten” from C++ to JavaScript, and the performance is pretty smooth. As a gamer, I must say that I’m very impressed!

This was followed by a demo of the latest features in Firefox for Android by Wesley Johnston. He showed us how smooth scrolling is (no more checker-boarding!) and some of the latest WebAPIs and CSS3 transitions in action. My favourite new feature is the reader mode, now available on the Beta – go check it out! Andres Martinez from Telefonica then gave us a good look at the new FirefoxOS on a real device. The Gaia UI has come a long way, he showed us the task switcher, music player, the browser and a game. It was nice to see music still playing in the background throughout the demo. Gavin Sharp gave us a preview of the new Social API that’s landing in the nightlies. The Labs folks had been working on it for a while, and it’s very close to actually landing in Firefox, thanks to a bunch of effort by Gavin & team. We tried to follow that with a WebRTC demo, unfortunately, we ran into technical difficulties while on stage Thankfully, we were able to successfully repeat the demo later in the day, during a session on WebRTC that Timothy Terriberry and I ran. Paul Rouget then took the stage and showed us some of the new developer tools hotness, including tilt and the command line.

The morning session had two more keynotes in store, David Slater gave us an overview of Marketing at Mozilla. He also revealed our top secret plan for marketing Firefox on desktop – more t-shirts! This was followed by caution that the strategy for mobile will have to differ, and a glimpse of what’s in store. Check out about:home in your Firefox for a cute little Android animation! He then invited community members to come forth with their crazy ideas, we’re going to need them to compete with other industry giants with piles of cash! Get in touch with Gen Kanai, he’ll patiently listen, no matter how crazy the idea The final keynote of the day was by Mark Surman, who gave us an update on various efforts by the Foundation, and like at CampusParty, made a case for building a generation of WebMakers. The Chad Vader Friday parody was played again, and good times were had!

We rounded off the morning session with a showcasing of the community quilt – a 90 second lightning talk by one representative from each community. I learnt a lot about how our community operates on the ground, what challenges they’re facing and what they’re most proud of. The rest of MozCamp was filled with sessions and fun activities, but I won’t get into the details of them all or this post will get way too long! However, I will mention that I loved the buddy program at this MozCamp. My buddy was Anas El Husseini, who does localization in Arabic, among other things; and we had a great time swapping stories. It’s just awesome to part of a community that’s so wide and diverse.

If you ever get a chance to attend a MozCamp, I’d highly encourage it – it’s a blast!

P.S. Slides from our WebRTC session are here, if you’re interested.

My primary focus at the event was to support the Firefox OS Challenge held by Telefonica. I spoke to a few developers on how to go about writing an app for Firefox OS, and some of the common pitfalls encountered when a website is converted into an app. I think the reception was pretty positive and it was great to meet folks who were pretty excited about Firefox OS. I was also extremely pleased that my Samusng Galaxy SII with FirefoxOS worked flawlessly through all the demos (yes, even the WiFi)!

You can find slides from my presentation here.

Mark Surman, the executive director of the Mozilla Foundation had a talk scheduled at the “free software” track.  His talk was about the Mozilla Foundation’s vision for promoting openness, innovation and opportunity on the web, with some interesting ideas on how to achieve that in the long run, over the next century. What I found particularly interesting was the notion of building a generation of Webmakers, i.e. ordinary people who know how the web works and are “literate” enough to write or hack a web page. This knowledge is mostly limited to computer programmers or engineers  these days, but Mark’s argument is that because the Internet is so vital and fundamental to human society, it is important that we educate the next generation about the web, just like we do with reading, writing and mathematics. The Webmaker project, along with tools like Thimble, X-Ray Goggles, and Popcorn are all steps in this direction. Chad Vader’s remix of Rebecca’s Black “Friday” was played at full volume during the talk, and at one point there was a caped man on stage. ’nuff said.

Next up was the charismatic Christian Heilmann, who spoke about Mozilla, the web and you. The talk covered a wide range of topics, with a focus on Mozilla’s latest efforts in the Mobile space, specifically Firefox OS. There was also a shout out to WebRTC, one of the projects really close to my heart, woo! Christian’s talks are always very entertaining, he has a blog post with links to slides and the recorded talk, which you should check out!

I also got the chance to visit the venue of our future MozSpace in Berlin. Mozilla Spaces is a project whose aim is to set up places around the world where the Mozilla community can come together to hack, design, research and all the other things Mozillians do to keep the web open. The tech scene in Berlin is pretty hot right now, and given the strength of our existing community there, it seemed like a fairly natural place to open up a MozSpace. The space is right on the historic Bernauer Straße, overlooking the memorial. There’s a lot of history behind the area, and the locality is filled with offices and co-working spaces for many other interesting startups. The San Francisco MozSpace has some serious competition with both the Paris and Berlin projects underway!

While strolling around Alexanderplatz, the city’s U-Bahn (subway) center and generally a very busy plaza, I was delighted to see Firefox Advertisements all over the walls. We did a small advertising campaign in San Francisco at the Caltrain station and the US-101 a few months ago, and this appears to be a continuation of that effort. Germany is known for its emphasis on Privacy (both Google & Facebook have had tussles with the German Government on such issues), so I hope the various messages resonated with the public. I don’t speak German, but I’m told the phrases were rather eloquent!

It’s been a while since I’ve been to a MozCamp (my last one was at Prague), and so I’m really looking forward to attending MozCamp EU in Warsaw. Tim Terriberry and I will be talking about WebRTC, and I hope to see some of you there!

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 partner apps that have 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!

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.

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!

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.

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!

I’m very excited, and I think it’s a great sign that on my first day of work I could start hacking right away. I’m indeed very fortunate to be working with some of the most brilliant people I’ve ever met; on a very meaningful mission of building an open web for the public benefit through innovation.

Stay tuned for more! Oh, and, have you installed the Firefox beta on your Android/Maemo device yet?