"Silk browser software resides both on Kindle Fire and on the massive server fleet that comprises the Amazon Elastic Compute Cloud (Amazon EC2). With each page request, Silk dynamically determines a division of labor between the mobile hardware and Amazon EC2 (i.e. which browser sub-components run where) that takes into consideration factors like network conditions, page complexity and the location of any cached content." (from http://www.amazon.com/Kindle-Color-Multi-touch-Display-Wi-Fi...)
This sounds conceptually similar to how Opera delivers pages with one of its mobile browsers, which is to say that Javascript and rich web apps will be severely crippled. Is it indeed possible for the server and client to collaboratively decide what parts of my code to run client-side and which ones proxy-side and still have anything approximating good performance/identical functionality?
From the video, I got the impression that they might even not be sending html, css and javascript at all. Instead they might be sending some javascript bytecode and a binary DOM tree.
The video explicitly states that the browser+ec2 work together to decide how to divide up the work based on network conditions, page complexity and other factors.
I would assume that to mean that if there's Javascript that can't be run on the server side, it will be run on the client.
I dont think there was any indication of javascript changes. At least all they mentioned was image and dns optimization, as well as prefetching and caching.
So... from the sounds of it... they rebuilt what Opera Mobile does and what RIM does with Blackberry?
They offload some of the compositing and some of the fetching and asset flattening server side, and then serve up to the device with custom protocol the pre-rendered flattened data anything that can be done server side. That is exactly the same way those other accelerator products already work for mobile.
While it's a nice design, it's been done. The limitations and issues are well know as well, like having trouble with private intranet sites and VPNs or that because all the requests come from a few centralized IPs, geoip doesn't offer any benefit (GEOIP is a hack anyways but sites use it and users get confused when their pages think they are where ever some colo is). It also creates a single point of failure which, pedantically, is counter to the design of the internet.
I was a little inflamed by the video's first statement that browsers have been built pretty much the same as they were since the beginning without many innovations. Sounds like marketing spin. I can name several notable amazing advancements in browser design since the days of WordWideWeb at CERN and Mosaic. A good number of amazing achievements around security for sure.
Also, on top of that, you know what happens when Silk touches Fire? It's not pretty.
(personal opinion, not opinion of my employeer rim)
The old Blackberry Java browser was split and had tons of logic in the cloud to compensate for the fact that networks were beyond slow and devices had no extra cpu and very little ram and it did make a huge difference. It feels like RIM bet big that networks were always going to be slow and cpu's wouldn't be that fast and then came along the iphone. These days networks are much faster and there are cell phone with dual core cpu's and GB's of ram. Just imagine what we will have next year! So it is all a trade off. Is putting resources into developing this hybrid browser worth more than developing something else and just waiting 12 months for faster network/devices?
Also while they don't say it on that page for the curious Amazon silk is using WebKit (from the jobs page).
So what? It sounds like it will greatly improve the browsing experience on a under-powered small-screen tablet. And it sounds like they have improved upon the Opera and RIMs implementations.
like having trouble with private intranet sites and VPNs
That's an edge case that could be ignored ("Kindle Fire is only intended for personal home use") or worked around (separate browser/browsing mode in those scenarios). EDIT: Reading below it sounds like they have an "off-cloud" mode.
because all the requests come from a few centralized IPs
This sounds like the tips & tricks you see in Pagespeed/Yslow, moving it to a proxy, coupling it with something like SPDY, and mixing in some server side caching. Which is neat, and no doubt will achieve some speedups. But I don't know if it is as revolutionary as Amazon is trying to make it sound.
There are also some serious privacy implications here. I don't really know if I want Amazon to cache & potentially record all my browsing, especially since that device is something they can directly connect to all my personal info (purchasing history, CC number, home address, etc..).
As more of us rely on our mobile devices to browse the net, and as this trend picks up, wouldn't this mean that Amazon has a unique vantage point to see what people are searching for, in terms of content, products etc?
With each product iteration or rollout, it seems like we are increasingly giving up more than our dollars at the point of sale, like privacy - allowing companies to have complete access to our browsing/spending preferences.
Does it seem like Amazon is solving yesterdays problem instead of the futures? With the speed of CPU's doubling every 18 months and the amount of bandwidth increasing by 50% annually, the accelerating growth of CPU's and bandwidth will leave this sort of client-server architecture behind. It's only a matter of time.
Your problems may not be their problems. Their "problem" is learning as much about their customers as possible. This solution precisely scratches that itch.
IIRC US bandwidth is increasing roughly 10% per year. I'm pretty sure it's some private company that does these metrics though, as I think this is the only thing the government releases:
I forget the exact numbers off the top of my head, but I just remember it being really difficult to actually find the statistic. But the takeaway is that although we are theoretically #27 in terms of broadband speed, our actual broadband speeds aren't that much lower than in other countries.
The Akamai report here is probably the most credible source. I remember there being one other report that covered this info, but I can't find it right now.
Yeah, my transformer is Tegra2 based and pretty quick with the rendering. Tegra3 is right around the corner. Whats the use of this,really? Save 4 dollars per unit on a cheaper cpu and a little battery, but paying for it by pounding EC2 servers? Heck, we're in the age of 4G and wifi. Slow 3G might be par for the course in the iPhone world, but not elsewhere.
Danger, Opera, and Blackberry have all done this with lackluster results. Mobile Chrome has the chops to handle the modern web. This kind of pre-rendered solution might have been a good idea 4 or 5 years ago, but now its questionable and brings up issues of privacy, vendor lock in, EC2 issues (hi, my website was down for 48 hours a couple of months ago), EC2 load issues, etc.
Bandwidth and CPU don't solve latency which today contributes most of your perceived page load wait, and thanks to current web practices, has been getting steadily worse. SPDY and Silk address latency.
Is that bandwidth figure representative of most Americans or worldwide? We have 25 people at our company in NYC, for example, and only one of them has a connection faster than your typical Time Warner cable line.
The fastest mobile phones (and even tablets) are still significantly less powerful than a netbook. Amazon's own devices will probably have even weaker CPUs than cutting edge mobile devices simply because the price point.
This suggests to me an interesting idea. Lets say you used the CSS media tag to include style sheets for 'e-ink', then if such a style existed you could 'send this to my kindle'. A sort of instapaper meets Kindle Publishing.
Amazon could pull something like that off, it would be useful to have a wordpress template that included the e-ink stylesheet.
I'm not a front end developer, but it seems to me that pre-evaluation of javascript, or even compiling the js into byte code, would be something that front end developers would want to try in order to speed up their own users' experience of their site. Is there anything that the cloud part of Silk is doing that can be applied to websites in general, regardless of what browser is doing the rendering? Or is this optimization uniquely possible because Amazon controls the browser itself?
For those of us working on mobile browsers this means a whole new set of implementation quirks we have to deal with even without the server side assist they are including. Even if they choose webkit as the rendering engine god knows what the event system will behave like.
The best news about this in my opinion is that websites can no longer block EC2 IPs if they want to work properly on the Kindle Fire... between this and free inbound bandwidth (now we know why they made that happen in the first place), scraping just got a lot easier.
It would be really interesting if they could integrate some form of parental controls along with this whole caching/prefetching/data crunching process.
Say you logged into your Amazon account and set the rating level for content available in Fire and then Amazon's servers would block your kid from accessing freepr0n4all.com. You could add exceptions, specific sites to block, etc. and there would be a known, ever-evolving database of "unsafe" sites by rating.
The ability to filter content in a mobile browser isn't something that exists as of yet, I don't believe.
If I could do this, I'd buy one for my 9yr old today.
Of course, this could then be combined with other tools to "lock down" the fire, e.g. disabling the ability to exit "cloud mode" and thus bypass the filters, password protection for app/movie purchases, like iOS parental controls do, and so on.
Honest question from someone who grew up in the era of web content controls: Do you really think you -- or any of us -- have the technical capability to stop another person from seeing something on the Internet if they want to?
It makes sense to try to help a young child keep from accidentally stumbling across that kind of crap, but I'm highly skeptical of the idea that you can prevent your child from looking at porn full stop-- or would really want to.
So it's OnLive for webpages; putting the client-side on the server-side. Well, half (or a dynamically allocated proportion) anyway.
But compositing dozens of network fetches from the same cloud, centrally caching the rest, and predictive pre-fetch are big wins. The endless traipsing back-and-forth is frustrating even on the desktop.
These aren't new ideas, but if Amazon implements them to deliver a better experience, users won't care - and neither will you. A sad truth for pioneers.
Also gives Amazon a competitive advantage: host all your stuff with us, users will love you (google's experiments showed that even fraction-of-a-second latency loses users.)
EDIT but... amazon.com is one of the slowest websites on the internet for me, and I'd expect them to be doing all of the above on their own site...
What about handling secure (https) connections?
We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com).
Amazon Silk will facilitate a direct connection between your device and that site. Any security provided by these particular sites to their users would still exist.
Opera Turbo is a similar service to this, but it doesn't intercept https connections. Hopefully Amazon's service will behave the same way. If not, there will be a privacy shit storm.
the SSL would have to stop in the EC2 instance where the bulk of the 'browser' is. Its then up to the Silk infrastructure to ensure the transmissions from the Fire to EC2 would be secure as well.
This Silk browser could be the "killer feature" of the Kindle Fire... something that allows it to really compete in the tablet space. It'll be interesting to really see how well it works in the real world and what the form factor of the Fire feels like.
I disagree. It is a good step for browsers everywhere, and hopefully will do more to push other browsers to use split processing, but the Fire will capture a new market of price-minded consumers who would never pay over twice as much for an iPad. Like Bezos said, it's all about bringing that level of product to a lower level price range.
[+] [-] moxiemk1|14 years ago|reply
This sounds conceptually similar to how Opera delivers pages with one of its mobile browsers, which is to say that Javascript and rich web apps will be severely crippled. Is it indeed possible for the server and client to collaboratively decide what parts of my code to run client-side and which ones proxy-side and still have anything approximating good performance/identical functionality?
[+] [-] ma2rten|14 years ago|reply
[+] [-] lojack|14 years ago|reply
[+] [-] erikpukinskis|14 years ago|reply
I would assume that to mean that if there's Javascript that can't be run on the server side, it will be run on the client.
[+] [-] cleverjake|14 years ago|reply
[+] [-] adamsmith|14 years ago|reply
[+] [-] pp13|14 years ago|reply
[+] [-] zbowling|14 years ago|reply
They offload some of the compositing and some of the fetching and asset flattening server side, and then serve up to the device with custom protocol the pre-rendered flattened data anything that can be done server side. That is exactly the same way those other accelerator products already work for mobile.
While it's a nice design, it's been done. The limitations and issues are well know as well, like having trouble with private intranet sites and VPNs or that because all the requests come from a few centralized IPs, geoip doesn't offer any benefit (GEOIP is a hack anyways but sites use it and users get confused when their pages think they are where ever some colo is). It also creates a single point of failure which, pedantically, is counter to the design of the internet.
I was a little inflamed by the video's first statement that browsers have been built pretty much the same as they were since the beginning without many innovations. Sounds like marketing spin. I can name several notable amazing advancements in browser design since the days of WordWideWeb at CERN and Mosaic. A good number of amazing achievements around security for sure.
Also, on top of that, you know what happens when Silk touches Fire? It's not pretty.
[+] [-] icefox|14 years ago|reply
The old Blackberry Java browser was split and had tons of logic in the cloud to compensate for the fact that networks were beyond slow and devices had no extra cpu and very little ram and it did make a huge difference. It feels like RIM bet big that networks were always going to be slow and cpu's wouldn't be that fast and then came along the iphone. These days networks are much faster and there are cell phone with dual core cpu's and GB's of ram. Just imagine what we will have next year! So it is all a trade off. Is putting resources into developing this hybrid browser worth more than developing something else and just waiting 12 months for faster network/devices?
Also while they don't say it on that page for the curious Amazon silk is using WebKit (from the jobs page).
[+] [-] naner|14 years ago|reply
So what? It sounds like it will greatly improve the browsing experience on a under-powered small-screen tablet. And it sounds like they have improved upon the Opera and RIMs implementations.
like having trouble with private intranet sites and VPNs
That's an edge case that could be ignored ("Kindle Fire is only intended for personal home use") or worked around (separate browser/browsing mode in those scenarios). EDIT: Reading below it sounds like they have an "off-cloud" mode.
because all the requests come from a few centralized IPs
Amazon's network is massively distributed...
[+] [-] justinph|14 years ago|reply
There are also some serious privacy implications here. I don't really know if I want Amazon to cache & potentially record all my browsing, especially since that device is something they can directly connect to all my personal info (purchasing history, CC number, home address, etc..).
[+] [-] Cherian_Abraham|14 years ago|reply
With each product iteration or rollout, it seems like we are increasingly giving up more than our dollars at the point of sale, like privacy - allowing companies to have complete access to our browsing/spending preferences.
[+] [-] smiler|14 years ago|reply
[+] [-] JeffL|14 years ago|reply
[+] [-] ceejayoz|14 years ago|reply
[+] [-] Steko|14 years ago|reply
It's true this problem is also being solved by LTE rollouts but those aren't today for most people.
[+] [-] uptown|14 years ago|reply
[+] [-] Alex3917|14 years ago|reply
http://www.fcc.gov/measuring-broadband-america
I forget the exact numbers off the top of my head, but I just remember it being really difficult to actually find the statistic. But the takeaway is that although we are theoretically #27 in terms of broadband speed, our actual broadband speeds aren't that much lower than in other countries.
edit: http://www.akamai.com/stateoftheinternet/
The Akamai report here is probably the most credible source. I remember there being one other report that covered this info, but I can't find it right now.
[+] [-] drzaiusapelord|14 years ago|reply
Danger, Opera, and Blackberry have all done this with lackluster results. Mobile Chrome has the chops to handle the modern web. This kind of pre-rendered solution might have been a good idea 4 or 5 years ago, but now its questionable and brings up issues of privacy, vendor lock in, EC2 issues (hi, my website was down for 48 hours a couple of months ago), EC2 load issues, etc.
[+] [-] Terretta|14 years ago|reply
[+] [-] bdickason|14 years ago|reply
[+] [-] baddox|14 years ago|reply
[+] [-] olliesaunders|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] cleverjake|14 years ago|reply
[+] [-] ChuckMcM|14 years ago|reply
Amazon could pull something like that off, it would be useful to have a wordpress template that included the e-ink stylesheet.
[+] [-] qjz|14 years ago|reply
[+] [-] ck2|14 years ago|reply
[+] [-] vitobcn|14 years ago|reply
[+] [-] taylorbuley|14 years ago|reply
http://aws.typepad.com/
[+] [-] tmcw|14 years ago|reply
[+] [-] josefresco|14 years ago|reply
[+] [-] commanda|14 years ago|reply
[+] [-] joshfraser|14 years ago|reply
[+] [-] johnbender|14 years ago|reply
[+] [-] bengl3rt|14 years ago|reply
[+] [-] tryke|14 years ago|reply
[+] [-] aforty|14 years ago|reply
[+] [-] jeffreymcmanus|14 years ago|reply
[+] [-] kellishaver|14 years ago|reply
Say you logged into your Amazon account and set the rating level for content available in Fire and then Amazon's servers would block your kid from accessing freepr0n4all.com. You could add exceptions, specific sites to block, etc. and there would be a known, ever-evolving database of "unsafe" sites by rating.
The ability to filter content in a mobile browser isn't something that exists as of yet, I don't believe.
If I could do this, I'd buy one for my 9yr old today.
Of course, this could then be combined with other tools to "lock down" the fire, e.g. disabling the ability to exit "cloud mode" and thus bypass the filters, password protection for app/movie purchases, like iOS parental controls do, and so on.
[+] [-] Cushman|14 years ago|reply
It makes sense to try to help a young child keep from accidentally stumbling across that kind of crap, but I'm highly skeptical of the idea that you can prevent your child from looking at porn full stop-- or would really want to.
[+] [-] 6ren|14 years ago|reply
But compositing dozens of network fetches from the same cloud, centrally caching the rest, and predictive pre-fetch are big wins. The endless traipsing back-and-forth is frustrating even on the desktop. These aren't new ideas, but if Amazon implements them to deliver a better experience, users won't care - and neither will you. A sad truth for pioneers.
Also gives Amazon a competitive advantage: host all your stuff with us, users will love you (google's experiments showed that even fraction-of-a-second latency loses users.)
EDIT but... amazon.com is one of the slowest websites on the internet for me, and I'd expect them to be doing all of the above on their own site...
[+] [-] colinprince|14 years ago|reply
[+] [-] johnpaulett|14 years ago|reply
[+] [-] mike-cardwell|14 years ago|reply
[+] [-] mildweed|14 years ago|reply
[+] [-] harrisreynolds|14 years ago|reply
[+] [-] miles_matthias|14 years ago|reply
[+] [-] guyht|14 years ago|reply
[+] [-] DanWaterworth|14 years ago|reply