Q&A: Inside Amazon’s Silk Browser for Kindle Fire
Q: Where did the idea for Amazon Silk come From?
A: Well, Amazon has been around for over 15 years, and we’ve learned a lot from the experience. One of our biggest takeaways from running the website is that people love a faster browsing experience–so we developed a passion for trying to speed things up.
For Amazon Silk, we got the idea to leverage the Amazon Web Services cloud; we’d let the work happen here instead. Some background on AWS: In 2006, AWS began offering IT infrastructure services to businesses in the form of web services — now commonly known as cloud computing. With the cloud, businesses no longer need to plan for and procure servers and other IT infrastructure. Instead, they can instantly spin up hundreds or thousands of servers in minutes and deliver results faster. Amazon Web Services has hundreds of thousands of customers in more than 190 countries around the world. With data center locations in the U.S., Europe, Singapore, and Japan, customers across all industries are taking advantage of the same services that Amazon Silk is leveraging.
Q: How does Amazon’s AWS service make Silk faster?
AWS offers more than a dozen different services, and is composed of many different parts–including Amazon S3, or Simple Storage Service, an infinite scalable hard drive in the cloud which is virtually limitless. And EC2, or the Amazon Elastic Compute Cloud, a horizontally scalable computer. Leveraging AWS is what makes Silk different. Amazon Silk employs a split architecture, which means that browser subsystems are present on the Kindle Fire as well as on the AWS cloud computing platform. Every time a customer loads a web page, Silk can decide dynamically which subsystems should run locally and which should run remotely. Silk couples the capabilities and interactivity of local devices with the computing power, memory, and network connectivity of the cloud. The result is a faster web browsing experience.
Let me give you an example; say we’re trying to load LaptopMag’s website on a mobile device. I’m looking it up now, and I see that you’d need to download 145 files, or 1.3 MB of data. How Amazon Silk would work is to dynamically decide how to split up the work that would need to be done between the AWS cloud and the mobile browser–depending on several factors–to give you the fastest possible browsing experience.
The EC2 host would download 145 of those files using a single optimized connector and deliver this to the Kindle Fire. And it will optimize for a variety of things. First of all, performance, which is a given. Second, battery power. We know that the device has limited battery power, so optimization happens so that you don’t burn out the battery on the device. Third, it also optimizes for network bandwidth. The Kindle Fire is Wi-Fi only, yes, but let’s say you’re using a hot spot that has a limited data plan–it optimizes for this by reducing the number of bytes of information that moves across the network.
Q: We’ve seen some servers being overloaded with activity before. Do you foresee that ever being a problem with AWS and Amazon Silk? Or is it a possibility that you’ll ever run out of space?
A: Short answer: I don’t think so. AWS is a huge resource, and we’ve never had a problem getting what we need. Another point to note is that Amazon S3 acts as the cache for all common web files across all devices, which will speed things up considerably. I don’t think there’s any conceivable way that we might run out of space.
Q: Other than the things you’ve mentioned, what makes Amazon Silk architecturally different from other existing browsers?
A: Again, we’re coming to this with 15 years of experience from Amazon.com. One other interesting thing about Amazon Silk that we took from the website — and you’ll be familiar with this if you’re a regular visitor of Amazon.com — one big feature is the recommendations algorithm, which reveals that customers who buy one particular product will likely end up buying other specific products, shown in our website as suggestions. This algorithm doesn’t save any information connected to users, and we don’t even need to know who the user perusing the Amazon homepage is. Likewise, Amazon Silk observes and learns aggregate user behavior patterns. It can guess the next webpage you’ll be likely to view based on the one you’re currently reading, using the same algorithm, and can actually pre-load it for you.
Q: But you start building your database with all-new data?
A: Yes, all new data based on aggregate behavior, which is collected in real-time.
Q: So what did it take to develop Amazon Silk?
A: Amazon Silk is built from the ground up on our own AWS infrastructure, which we’ve been working on for over 8 years. And I love working at Amazon, I’ve been with the company for a number of years now — many of our best ideas come from the bottom up. This was definitely the case with Amazon Silk. Some engineers on our team came up with the idea and put together a prototype. They tested it, targeted a small set of pages to see if they could make them load faster — and it worked. Then we expanded the project.
Q: Are you aware of any other projects similar to Amazon Silk that are in existence?
A: I guess you could say that Amazon Silk has been compared to other things like existing proxy-based solutions, but there’s really nothing like it. The unique thing about Silk is the dynamic way we’re doing things. The way we treat pages, like LaptopMag or Google… No one else makes the decision page by page like we do. There’s also the notion of observed speed — if the network seems slow or fast (like if you’re connected to Wi-Fi or just a hotspot) it notices and optimizes your browsing experience for that as well.
Amazon Silk runs on the client, Kindle Fire, and on the backend, you have AWS and EC2. All Web traffic is encrypted by Amazon from its AWS servers to the Kindle Fire’s Silk web browser, and Amazon uses Google’s SPDY, which facilitates a single connection that is always encrypted. That means that Web surfing, even in public hotspots, will be safe–you don’t have to worry about attacks from Firesheep and similar attack tools.
Q: What sort of maintenance is needed for the Amazon Silk browser (from both the user’s perspective and on the back end side of things)?
A: From the user’s perspective, I don’t think any maintenance is needed at all. The browser can do what every other browser can do as well — create and delete bookmarks, etc. It’s fully featured. On the back end, well, Amazon has a long history of running large-scale production systems. Our software engineers are experts at building things that are highly scalable and highly available. One question we often get, actually, is: Can people just build the same thing? And the answer would be theoretically, yes. The pieces are out there, and anyone could theoretically build it. But no one else has.
Q: There’s also been some talk about security issues on the Amazon Silk Browser.
A: Yes, and the EFF (Electronic Frontier Foundation)’s statement on our response was quite accurate and complete. Each user gets a completely random identifier as long as Kindle Fire is open, and nothing can be linked back to the user at all. Amazon Silk logs aggregate browsing information — the logs are not associated with customer identities. Logged information is restricted to the URL being requested, the timestamps, and the token identifying a session. And logged data is kept for only 30 days.
Customers have the option to turn off the cloud acceleration feature of Silk (if, for instance, your ISP is messed up or something). It sits right in Settings — Accelerated Browsing. In that “off-cloud” mode, web pages go directly to a user’s device rather than pass through AWS servers, and customers still enjoy a good browsing experience (though it cannot be as fast as with cloud acceleration turned on).
Q: Do you have any future plans for Amazon Silk? Any new features in mind?
A: [Laughs] Well, without telling you our long-term plans… We do have a to-do list for Amazon Silk that we plan to implement soon. Some are obvious features to improve the user experience, and others will be happening behind the scenes (on the back end). We’ve got a lot of new stuff coming out, so we hope you stay tuned.