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!

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!

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

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!

However, I felt like I was drifting too far away from what the majority of computer users operate on, even today. Not to mention, my roots are back in the Linux world, and in the back of my mind I’ve always wanted to switch back to a “PC” (the term in quotes, because Macs are PCs too!). I had heard great things about how much better Windows 7 and Ubuntu are than their predecessors, so I decided to take the plunge.

For work, I settled on a trusty, hardy Lenovo Thinkpad. The new x201s have great battery life, portability and power. I’ve really been enjoying dual booting Windows 7 and Ubuntu 10.10 on it.

When it came to my home computer, I wanted to get one of those beautiful 27″ iMacs. However, Starcraft2 happened to release around the same time, and I found myself questioning the value of a computer that could not run it in ultra graphics mode. For the same price as the iMac, I was pleasantly surprised to learn that I could hand assemble a computer with most components near the cutting-edge. Awesome!

Ingredients

So I got to work. It is very convenient to order all the parts you need for a computer on Amazon. Let’s go through what you need:

• CPU: Processor manufacturers have already hit the ceiling for how many transistors they can pack per square-inch, but now the race is towards how many separate ‘cores’ are available. Most software don’t even bother using more than one core, so the quad-core CPUs from either Intel or AMD should be more than sufficient for the next few years: I opted to go for the Intel Core i7 950 3.06GHz. You’ll want to note the socket type of the CPU and make sure you get a compatible motherboard (the i7 CPUs fit into LGA-1366 sockets).
• Motherboard: Pretty standard choices these days, the differentiating factors are usually overclocking support, USB 3.0 & SATA 6gb/s throughput, and the number of PCIe slots. You’ll want to make sure to get a motherboard that matches the socket type of your CPU. I opted to get the ASUS P6X58D Premium.
• RAM: 32k may have been enough in the past, but you want to make sure you have atleast 4GB to stay competitive today DDR3 is pretty much the faster consumer memory you can get in the market. I’ve heard that 1600Mhz is the sweet spot for i7 processors, going any faster won’t give you any significant performance boosts. I got a handy pack of 3 x 2gb sticks: Corsair Dominator 6 GB 1600MHz.
• Graphics Card: It’s what puts pretty pixels on the screen; if you’re a gamer or design professional you’ll want to go all-out. I think having two cards in SLi (nVidia cards) or Crossfire (ATi cards) is much more efficient than getting a single very high-end card. Before you get two cards, make sure your motherboard supports the configuration and keep in mind that you can only link identical graphic cards. I chose to get two of the Gigabyte GeForce GTX460 1GB cards.
• Power Supply: You get power supplies ranging typically from 400W to 1000W and you’ll want to choose one that keeps up with your hungry processor and graphics card, while still being economical. I got the Corsair CMPSU-850TX 850-Watt to fuel the two GTX460s and to give me a little room for expansion in the future.
• Hard Drive: Solid state drives are catching on and becoming less expensive everyday. The performance boost is phenomenal, and I would highly recommend getting one for your boot drive. I got the Crucial Technology 128 GB RealSSD C300 because Crucial has been getting great reviews of late. You’ll still want a much larger regular spin disk, however, to store your movies, music and photos (the 128GB should be used only for your OS and frequently used applications). The Western Digital Caviar Black 1TB hard drive is a solid choice.
• Tower: Finally, you need a case to put all of these parts in! While choosing a tower there are two sizes you need to consider: the ATX size which specifies the largest motherboard the case can accommodate, and the tower size itself which defined how much room for expansion drives, cards and ventilation there is. I got the Cooler Master HAF932 ATX Full Tower.
• Keyboard, Mouse, Monitor, Optical Drive: These are all essential components of a computer but there really isn’t much to it. It’s mostly a matter of personal preferences. Just look around and pick one you are comfortable with. My choices were: Razer Lycosa Programmable Backlit Gaming Keyboard, Razer Mamba Wireless Gaming Laser Mouse, HP 2509m 25-Inch Diagonal Full HD LCD Monitor and Samsung Blu-Ray Internal SATA Drive with Lightscribe.

You do need a couple more things before you can being assembling your computer. A grounding wrist strap and a toolkit are highly recommended. Setup a nice hard, flat surface to work on.

Recipe

1. The first thing you’ll want to do is to mount your CPU on your motherboard. For the LGA1366 this was as simple as gently placing the CPU over the socket to match the nudge and then pulling the lever to lock it in. I had to put some pressure to lock the lever, but I only did it after I was sure I placed the CPU in the right orientation.
   
2. All the AMD/Intel CPUs will come with their own stock coolers. Mounting them on top of the CPU is very easy these days, as they come with pre-applied cooling paste. Just follow the instructions from the CPU box. I opted to get my own cooler and coolant, however, so mounting it was a little more involved.
   
3. Now you’ll want to attach your power supply to your ATX tower. It usually goes in the extreme bottom or top of the tower.
4. I prefer to attach RAM on the motherboard before mounting it on my tower so I have a better sense of where to place the PCIe cards. It’s also easier because your hands are constricted once the motherboard goes inside, and RAM sticks typically need to be absolutely vertical to their slots before they’ll go in.
   
5. Once you have the RAM in place, it is time to secure the motherboard onto the ATX tower. The most important step here is to first attach the double-edged screws that came with your motherboard. They raise your motherboard and provide screw sockets for the ATX to attach to. Do not try and attach your motherboard directly to the tower without putting these in between. There should be a half-inch gap between the metal casing and the lower side of the motherboard.
   
6. The hardest part is now behind you. Plug-in your video card, RAM and drives. Most of these are pretty much “push-click” based these days, really nothing much to it!
7. Done? Now all that remains is to tie everything together. This might actually be intimidating to some, but cables these days are designed not to fit in something they weren’t meant to. The basic steps are to connect power to your motherboard, video card, fans, optical and disk drives. Then, connect SATA cables from your drives to the motherboard. Motherboard control pins go to the front of the ATX (for LEDs and power switch).
8. Take a deep breath. Connect the monitor and a keyboard and flip the switch. If all goes well, the fans will start whirring; and you’ll get a beep from the motherboard indicating POST succeeded. wOOt!
   If that didn’t happen, maybe you got something other than a single beep. Different kinds of beeps can mean different problems, go the Wikipedia page on POST to troubleshoot. If you don’t get any kind of beep at all, and the fans aren’t spinning it means you missed a power supply cable somewhere. Double check to make sure the CPU cooler fan is running! If it isn’t your CPU will heat up very quickly — most processors will automatically shutdown when they overheat — but there’s a chance it may damage your computer, so double-check.
9. Get your installation media and put your favorite OS on your brand new computer. Give it a name, and learn to love it

That’s all there is to it. I certainly had a blast assembling my computer, it was a nice learning experience; not to mention very economical. Well, I’m off to play some HD-quality Starcraft2!

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?

Indeed, I have observed many of my peers from different countries and cultures increasingly identifying themselves as agnostic or atheist. In the Netherlands, where I spent the last two years, a large portion of the population (42.7%) specify that they are not affiliated with any religion. Even though the country where I am from, India, is regarded by many as a deeply religious (secular) state; I never cared much for religious teachings or rituals. I’ve met many students like me, who regarded science to be a guiding compass, with a few basic moral principles (such as: don’t hurt anyone) at the foundation. With the abundance of destructive events all over the world – inspired by religious fanaticism – it is not surprising that I grew increasingly suspicious of the concept in itself. I found the TED talk by Sam Harris, on how science can provide a moral compass, greatly moving and convincing.

For those who think like me, and lay more faith on science than religion; or identify themselves as agnostic I present to you the following passages written by C. Rajagopalachari, a well respected Indian statesman, commonly hailed as the ‘conscience-keeper’ of the Mahatma. Though it is rather long, I found it quite interesting:

A little knowledge of the laws of nature and the wonders of science, specially when that knowledge is acquired second-hand without the chastening influence of effort and investigation, acts as a wine on some natures. Their sense of proportion is unset. The unknown is not only unknown but ceases to exist for them. Holy books and scriptures seem to them ancient folly; nay worse, they are looked upon as instruments and deliberate devices for the practice of fraud. But those who have struggled to obtain a deeper knowledge of the physical sciences and who, therefore, know enough to retain their sense of proportion and judgement know that the vast unknown is ever so much more than what is known and that while human intelligence may bring under its domain more and more as time goes on, there is a residue that cannot be either ignored or brought under the sway of man’s intelligence. Men of science not only preserve their humility but on account of their very knowledge of some secrets of nature, contemplate with increased humility and reverence that which must ever remain outside the pale of human analysis.

The cause of all causes, the law of all laws cannot be seized by the highest effort of human reasoning or investigation. Human reason is so perfectly fashioned and rounded off that there is no room for any sense of limitation. But the fact remains that the part cannot comprehend the whole, however excellent it may be shaped. The symbol of the serpent with the tail in its mouth as if swallowing itself illustrates the limitation of the human mind in its efforts to grasp the All. Even a giant cannot stand on a platform and lift itself also. We cannot jump off the ultimate cause on which we stand and on which we depend for every motion of the mind, in order that we may get round it or measure it.

This limitation of human knowledge is a familiar boundary in scientific and philosophical investigations. Dive into any truth or investigate any phenomenon or examine any distinction deep enough, and at a certain point we reach the unknowable and further progress is stopped. We strike against God, so to say, in everything. The unknowable is all-pervading. The known and knowable make up but a thin surface-crust over the mystery-sphere of infinite dimensions. Religions and holy books, and the saying and doings of holy men deal with this infinite unknown, not as a science deals with matter, but in a different way which is also the only possible way.

It may be asked why anyone should worry about the unknown. Of what use is it? The answer is that to ignore the real is foolish. The unknown is no less real because it is unknown. We know this much about it, that it is there and has profound relation to all that exists, including ourselves. How then, can we ignore it? The gap in human perception, we know, is not a void but filled with the most important reality, although we cannot dive into it, analyze it or understand it. In the material world, does not the mathematician deal with quantities that are too great or too small for definition, and with expressions that are for the human understanding wholly unreal?

Infinity, zero and surds are not neglected in mathematics, but go greatly to make up a science which actually helps engineers and mechanics to build real and useful construction. The insoluble and the infinite are thus neither unreal nor useless even for practical life. What is said in the holy books of the world may often not be as precise or clear as we would want it to be. The explanations are not as satisfying as the proofs we find in the physical sciences. This is necessarily so because the matter is wholly different and the approach and methods of application also must differ. Things within the domain of human reasoning can be defined and proved. But for the understanding of things beyond, faith and meditation have to function. The scriptures and holy books may be looked upon as helps to assist reverent meditation, by which alone the human mind can get glimpses into the truth beyond. By cultivation of purity of mind and action, and by meditation and prayer, what sounded first but as an empty jingle of antithetic phrases gets substance and meaning. What was obscure gets a strange and new light by which we may see through dimly, and though, even that, we may not all be able to relate to others. Thus it was our fathers saw, and thus again we may also see.

A reverent spirit is necessary to understand any religion. To start with a suspicion that the founders and teachers of religion in any land were skilful deceivers, interested in some sort of scheme of self-advancement or the advantage of some particular class, and that the rest of the people were duped to regard these deceivers with unbounded reverence and affection, is foolish in the extreme. The mass of people of ancient days, from whom, indeed, we have inherited all the intellect we possess were as practical as we are, were as interested in knowing the truth about men and things as we are, and were, if it may be so put, as suspicious as we are. They had probably as much intellectual acumen as we have, and had indeed more time to examine men and things. To believe that they were duped and that among them there were not men intelligent and bold enough to prevent the mischief is to proceed on a wholly wrong assumption. The religions that have commanded the devotion of successive generations of normal human beings in any country have done so because by direct personal contact at first, and by experience handed down as tradition from one generation to another, the founders and teachers of the religions were known by their contemporaries to be good, sincere and deep-thinking men, worthy of being followed. It is not merely wrong to display the detective-police mentality when studying a religion; it incapacitates one even to understand it. Undoubtedly personal and class interests have perverted religion as they have perverted other institutions. But to confuse the latter with the earlier and to impute fraud to the source is an unscientific attitude of the mind in the investigation of truth. It is in a spirit of reverent affection that we should approach the study of an ancient scripture.

This is perhaps the most convincing argument I’ve personally heard in favor of not dismissing religion entirely.

I believe that the root cause for many kinds of suffering is because of man’s nature to try and convince another of the ‘right’ way to live. I do not wish to fall in that trap, and thus I will leave it to you to interpret the passages as you please. But, I did feel it was worthy of sharing because the argument not only answers several doubts I previously had about religion, but has offered to me a scientific basis for at least being inquisitive about something that has survived for so long.

I’d love to know what you think.

It’s been a couple of months since I deleted my facebook account. It wasn’t an impulse decision, and I had been mulling over it for a while before actually going through with it. I don’t really miss it, which I suppose, is a good thing. As a technology enthusiast however, I do want to keep up with what the biggest social network in the world is up to. Create an alias you say? While signing up for one, I noticed that the form very strongly notes that one is to use their “real name only”. Interesting. I’m just going to wait and see if they decide that I am a fake person.

All that is well and good, but my conversations with new and interesting young people I meet almost always ends with “are you on facebook?”. My response is usually met with either mild surprise or a sliver of disappointment. I quickly explain that it doesn’t mean they can’t get in touch with me but that leads to a look that I’ve come to interpret as “yeah right”, also known as “ugh, email”. Which explains why my personal inbox only contains messages from my mom, the British lottery council and my very wealthy friends in Nigeria.

This leads us to the burning question of why “standard” messaging protocols like SMTP have failed (or rather failed to evolve) to capture the interest of this generation. As Chris Beard very succinctly put, if you had said we’d be using a single Internet based service to communicate with each other in the 90s we’d have thought you were crazy, simply because we were just finished with the nightmare that was AOL. Yet, only a couple of decades later it seems we’re at a full circle.

Hypothetically speaking, if Google had decided that Gmail could only be used to send messages to other Gmail users, would it have gained as much traction as it did? Yet, millions of Facebook users seem to miss the absurdity in the fact that they can’t use the service to talk to anybody who is not a member of the network. If users fail to recognize this simple drawback, it must mean that playing the ‘privacy’ trumpet or the ‘centralized control’ horn is just wasted effort.

What can we as computer scientists do about the situation (or does the situation even need our attention)? David very rightly points out that the last thing on our minds should be to ask users to stop doing things they absolutely love. I enjoyed facebook. A lot. There is a reason (actually several) for why the service is so popular. It certainly seems to me that understanding the basics of why such a service is a grand success is an interesting exercise in itself.

So, are you on facebook? What do you love about it? What do you think could be better? Do you see initiatives like diaspora succeeding?