I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Quick Amazon Silk thoughts

So Amazon has announced its Kindle Fire tablet, and it will not be an iPad killer. It runs Android, but not the standard Android, but rather a special Amazon port that does not include any standard Google apps. Notably, Amazon will have its own app store.

Update: I've asked a few questions of the Silk team. Now let's hope we get an answer.

The Kindle Fire will also sport its own browser: Silk. Kudos to Amazon for actually giving their browser a name. That helps a lot.

Yesterday I was surprised at the fact that so many people were surprised that Amazon would use its own browser. What else would they have done? Copy Android WebKit, the most disappointing mobile browser right now? Android WebKit is hardly progressing, and if you want a state-of-the-art browser you’d better build something yourself.

On the positive side, Amazon actually created a blog about the new browser — something you rarely see in the mobile world. On the negative side, it’s bloody vague:

Amazon Silk deploys a split-architecture. All of the browser subsystems are present on your Kindle Fire as well as on the AWS cloud computing platform. Each time you load a web page, Silk makes a dynamic decision about which of these subsystems will run locally and which will execute remotely. In short, Amazon Silk extends the boundaries of the browser, coupling the capabilities and interactivity of your local device with the massive computing power, memory, and network connectivity of our cloud.

Some tantalising hints, but mostly marketing speak. Let’s deconstruct it. See also this article and this one.

• Silk uses WebKit. That’s good.
• Right now the Kindle Fire lacks a 3G model. However, I feel the browser has been made ready for 3G. (Why? Forward compatibility to next-gen Kindles, and see also below.)
• Silk seems to be contain an Opera Mini-like proxy browser, where the client asks the server to fetch and render the page, and then receives what’s basically a bitmap image. This makes for very fast browsing and little data traffic. (See also update below.)
• An engineer describes it as a store for accessing your files — which reside in the Amazon cloud. That’s a good way of explaining cloud-caching.
• Still, cloud-caching won’t cut it on a 3G network. The problem there is not the connection between the Amazon cloud and the website, but between the Kindle and the Amazon network.

Michael Mace discusses the Kindle, and makes an interesting remark:

Amazon could tie the browser to its own content services and distribute it to other hardware vendors. Basically, it could try to make Silk the content layer on Android that Google wants to be. This could be a good business move for Amazon, since it's not making money from the hardware anyway.

Technically I’m not quite sure how a browser could be a content layer, but that’s mostly because I lack technical information. Of course the browser could tie in with, say, the e-reader so that it can access your ebooks and other content. We’ll have to see whether that is the case, though.

If that is the case I wonder if Silk can run on a regular Android device. Now that would piss off Google: Amazon would take over their entire content layer in one fell swoop.

And why stop at Android? Thin Silk client offering a gate to your Amazon content on other OSs? Say, on iOS? The main problem I’m seeing here is that it would need caching on the device itself. The cloud won’t cut it if you’re on a lousy mobile connection and want to read your e-book.

I could be completely wrong here; I’m arguing from severely incomplete information. But the ramifications of a thin Amazon client are intriguing.

Update: Some say that Silk is a hybrid browser: it can function either as a proxy browser or as a full browser. Now this could be true. In fact, it was what I originally thought, but I changed my mind after watching the Amazon video, which basically talks only about proxy aspects.

If Silk is indeed a hybrid browser Amazon is doing its best to confuse the world.

And if Amazon ever wants to expand its browser (and thus its content) to other platforms, a proxy browser is what they need. It’s much easier to write a thin proxy client for dozens of platforms that a hybrid browser that also contains a rendering engine.

Update 2: A comment on Hacker News points out I’ve overlooked something in the introductory blog post:

Amazon Silk deploys a split-architecture. All of the browser subsystems are present on your Kindle Fire as well as on the AWS cloud computing platform. Each time you load a web page, Silk makes a dynamic decision about which of these subsystems will run locally and which will execute remotely.

So it’s definitely a hybrid browser.

In my defense, nobody else (except for commenter spjwebster) seems to have noticed the crucial sentence, either. And Amazon spent just about all of its time explaining the proxy browser concept as if it’s something completely new.

(That’s the problem with those US companies: they always behave as if nobody else has ever thought of anything even remotely similar, even when the concept is years old. I wonder if Opera has thought to patent the proxy browser.)

So it’s a hybrid. Still, I assume they can leave out the full browser on the device and create a new thin client for basically any platform — with your Amazon content on it. That continues to be the most interesting novelty the Silk browser introduces.

Update 3: I’ve thought some more about this, and it occurs to me that by producing Silk clients for other platforms Amazon could capture the browsing habits of these platforms’ users, too. That, and not spreading their content services, may be the most important point of creating a proxy browser.