Kindle FireA few days ago I wrote about Amazon’s Android tablet, which has now been formally announced as the Kindle Fire. In reality, the Fire is just a low-rent Android tablet with a small screen and a re-skinned UI combined with a stand-alone app store. This is all fine and actually pretty cool, because it might be a decent tablet that is available for only $200. I was talking with my wife, an avid Kindle user, the other night, and she was very enamored with the concept, largely because of how much she likes the original Kindle. Because of that and the price point, I imagine Amazon is going to sell A LOT of these, I doubt it will be a flop in the same way that HP’s WebOS tablet was.

The interesting part, however, is Silk. Silk is Amazon’s new browser technology, which uses cloud-based rendering to speed up pages by caching content and preventing the tablet from having to generate dozens of HTTP requests per page, instead only having to generate one to Amazon AWS servers. Gizmodo does a good job of explaining this:

Amazon Silk is a web browser optimized for the Amazon Kindle Fire hardware, which runs Android Gingerbread. The main focus of Silk is to take the processing load off of the Kindle Fire CPU/GPU. Silk is referred to as a Split browser. It knows what web processing tasks the tablet can handle well, and which ones it cant. The lighter processing will be handled by the tablet hardware, while the heavier code crunching (HTML, CSS, Javascript, etc.) will be sent to Amazon’s cloud servers which have more muscle in the areas of RAM and CPU power. Loading a single website requires initiating multiple connections to multiple servers. For less powerful devices, this process takes more time than it would for a more powerful machine. Better equipped to handle this process with its powerful optical network, the EC2 backend will take websites and optimize them for the Kindle Fire’s screensize/resolution so that the device has an easier time digesting those pages. Optimized pages means smaller file sizes. But Silk will also cache sites you’ve visted on the EC2 servers, thus keeping more of your storage free for cooler shit.

If you read between the lines, however, there is something crazy going on here: For “Silk accelerated” pages, all traffic is going through Amazon. That means they have access to everything that users view, they could theoretically throttle traffic from websites like, let’s say, Barnes and Noble, and they can do even sneakier things like stripping certain URL’s to prevent Google from being able to mine usage data like they do with other Android devices. This is a pretty profound step in the information war for Amazon, currently being waged by Apple, Google, Facebook, Twitter, and others. The amount of information that is able to be mined and sold from having a product that you control in the hands of massive numbers of consumers is staggering, and is a large source of revenue for these companies. As mobile devices begin to rely on the cloud more and more, Amazon will likely not be the only company to try something like this. Rob Malda, or CmdrTaco from Slashdot, shares my concern:

But if the Fire becomes widely adopted, web masters will start seeing large blocks of anonymous traffic arriving from this mysterious network of amazon IPs.  Being unable to distinguish one anonymous user from another, you’ll have to be very careful of large scale anonymous attacks that could be launched via the network. I ask the more serious question: do you really want all your packets flowing through amazon?  Do you think they would slow down the packets to barnes & noble?  Do you want to be reliant on their systems to be stable and fast so that you can use your device?  Is that worth saving a couple hundred bucks?

I think the question a lot of people are asking is: how long before Apple comes out with iCloudQuartz, or if they’re really lazy, iSilk? As a developer, I’m certainly very interested to see where all of this cloud-rendering technology goes.

Similar Posts: