Binary Sunrise

Jan 17 2012

PIPA/SOPA: Not good for anybody’s health

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

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

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

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

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

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

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

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

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

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

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

Dec 15 2011

4 Comments

FOSS, Mozilla, Programming, Technology

Behind the Mozilla Apps Developer Preview

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

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!

Nov 11 2011

11/11/11

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

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

Aug 02 2011

7 Comments

Mozilla, Technology

Why should you encrypt user data?

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

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

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

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

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

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

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

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

Mar 04 2011

Apps

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

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

The role of Statefulness

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

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

Open Web Applications

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

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

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

Feb 02 2011

2 Comments

Fun, Hacks, Technology

Project Assemble

Ever since I participated in the first Summer of Code 4 years ago, I’ve been using Macs almost exclusively. I really enjoy using them – they’re great machines for developers, and the amazing virtualization options make them practically the only development computer you’ll ever need.

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

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.
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.
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.
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.
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.
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!
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).
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.
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!