"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.
Opera has their own server infrastructure for Opera Mini, although I'm sure it could run on EC2 as well. For a while all the servers were in Oslo, Norway, but now they have servers around the world. Here's an article from last year where they installed some new servers in Iceland: http://my.opera.com/portalnews/blog/2010/11/01/20-million-op...
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.
How's it mind boggling that a single SPDY connection to a distributed network that has nearly unlimited bandwidth and computing power would be faster than having a mobile device negotiate its own connections?
Even if it was just a proxy for resources it would be way faster, but they gain the benefit of knowing what resources are needed based on past events and likely already having them cached. Not to mention all the sites that will be local to AWS.
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.
On the page I link to, Amazon says "We've refactored and rebuilt the browser software stack to push pieces of the computation into the AWS cloud. This lets Silk do more work, more quickly, and all at once. We call this “split browser” architecture."
Computation (in the context of webpages) indicates JS to me, though they concievably could mean DOM construction. I'm fairly skeptical that transmitting a serialized DOM and unpacking it could be more efficient over mobile network connections that is using our time-honored DOM serialization, HTML.
I do hope I'm wrong, as I can't see how this sort of proxy can be healthy for the web, but I don't think my speculations are out if the realm of reasonable given the information.
A binary DOM would be much more efficient than HTML, by an order of magnitude or more. When I was working on the BlackBerry browser we did the same thing and had gains at least as big. The problem comes when you have document.write calls in scripts, and start getting dynamic content inserted during parsing. That gets really tricky to handle in a server-side environment if it depends on client-side properties or user input.
Very true - this is what old WML based devices use to do - WML got compiled to WBXML or WMLC (depending on who wrote the docs :), and that got sent to the device, making much easier to handle parsing for the device. There were really big speed ups both computing wise - but (especially in those days) also transport.
I don't know how Amazon is doing it with Silk, but I'm guessing they're seeing enough of a speed up to make it worthwhile.
The Kindle Fire is wifi-only, and Silk is only on the Kindle Fire. They are probably optimizing battery and latency. Bandwidth is important but not as important as if they had to deal with 3g.
The main reason I'd be happy getting a Wi-Fi tablet is that 3G smartphone based hotspots are becoming ubiquitous. I'd imagine they'll be tuning for that usage as well as couch surfing on home broadband, possibly even intelligently moving more work to the cloud when it detects a slower connection.
That's an interesting point. Most WiFI APs are pretty snappy. Optimizing EDGE connections and weak cellular signals are one thing, but how much faster can it really be on my a 10GPS down connection?
A ton. When you request a site in Silk it's very probable Amazon already knows about all the dependencies and already has them cached locally. So you make a request for a site (in the existing SPDY connection) and in return get everything needed to display it at once. In a pre-computed format so the relatively slow mobile CPU doesn't have to spend cycles parsing it into something readable.
Just the CPU thing makes a big difference. There's a noticeable timing lag between loading a page on my iPad vs on my computer. Same wireless network so it's not the connection slowing things down.
Even if a binary DOM was the same size as HTML (it would actually be much smaller), eliminating the cost of parsing HTML (forgivingly) and serializing it into a DOM would be a significant improvement.
Similarly, even if JS bytecode was the same size as the JS itself, eliminating the cost of parsing, constructing an AST, (possibly) transforming the AST, creating bytecode, and (possibly) doing an optimization pass on the bytecode would be significant.
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).
Agreed. The most interesting part of the announcement is the mention of dynamically selecting which components of the browser run on the server and which run on the client. I wanted to get more details on that but can't find much. I'm interested in how they carved up WebKit and the interfaces between the different modules that might get serialized over the air.
Well a good chunk of it doubt is all in the Network layer which is outside of "WebKit". Image compression, dns, fetching, pre-fetching, streaming, etc. You can no doubt get tons of win just by having a proxy server that gzip's everything that can be that isn't already. But that is just the tip, they mentioned image re-compressions, but what other trivial things like stripping javascript and html to reduce size.
But you could also do things like pre-compile the javascript and only send the bytecode down to the browser (starting to get in the relm of cool).
And we still haven't touched the dom. Of course the more you touch the harder it is to keep up to date with webkit.org. The real meat of this entire discussion has to be what gives the best bang for the buck? For WiFi devices all of this (guessing) is a waste of resource as my guess is that it doesn't improve the speed by much. I would expect the performance jumps on a cell network to be much better. So when is that device coming out?
With the old BlackBerry browser, MDS did image re-compressions using the Slipstream image libraries, and javascript pre-compilation for the ecma engine. It helped, but only so much. Reducing image sizes turns out to not be applicable all that often, unless you're not letting the user zoom in to 1:1 size. Degrading image quality (invisible to the average human eye) helps though.
If all they're doing is network stuff then there's nothing new here, and I doubt their gains will be very noticeable. I was hoping for something more involved.
<i>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.</i>
Amazon is betting that slow hardware will stay cheaper than fast hardware. It's a good bet. If they could ship a $30 Kindle, they absolutely would. And eventually, they might.
And it isn't to say that both are good biz models.
Expensive (high margin) fast hardware that can do more things
Cheap (low margin) slow hardware that can do some things
The one thing we do know is that WebKit is winning. Now the big question is which JavaScript engine did they use? My gut says V8 due to the optimizations I know they could do with the cloud setup they have.
(disclaimer work for the webkit team at rim and this is all my own personal opinion)
Well, as the networks/devices get faster, the web pages will get bigger and load more javascript than every before. We have already seen how the html/js/css growth has been since early 2000s. If not for that, all those pages with 10 years of growth of network/devices speeds, we should've blazing fast web right now!
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
Sure, it's been done. Why do consumers care? They don't really. Is this for news developers? because not much meat here for the dev crowd and they aren't announcing anything exciting here.
Also Amazon's cloud isn't so massively distributed that it's in every single ___location that some how makes GEOIP work which was the point.
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..).
To be fair, Amazon is doing what our ISPs do already: cache sites to deliver it faster.
Also, Amazon's privacy statement says you can make Silk a normal browser by selecting the "off-cloud" mode [1]. Off-cloud mode allows web pages to go directly to the device rather than pass through their servers. I'm sure most users won't know of this option but at least it is an option.
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.
"You can also choose to operate Amazon Silk in basic or 'off-cloud' mode. Off-cloud mode allows web pages generally to go directly to your computer rather than pass through our servers. As such, it does not take advantage of Amazon’s cloud computing services to speed-up web content delivery." [1]
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.
To a point; for the vast majority of users, the increase in hardware requirements for modern desktop tasks plateaued quite some time ago. The exception to this is video games; they've continued to drive hardware advancement on the desktop.
Mobile devices are nearly on par with where that plateau began, and there are plenty of reasons to increase the CPU/GPU performance for the purpose of games. In this context, it certainly appears to me that Amazon is wasting their resources on what amounts to a massively complex privacy snafu.
The devices are fast enough, but with that speed came massive battery life problems. Therefore, the same problem exists, its effects have just moved somewhere else. It is therefore not comparable with the desktop.
... but Silk is being rolled out on a WiFi-only tablet. Most users won't ever have to worry about a crappy cell data connection.
Some day, sure, they'll ship with 3G connections. But client hardware on future devices will only be faster and more capable.
A SPDY-link to Amazon's private caching/compression network is a great win and differentiator. But why even open the can of worms that is two-tier _processing_?
If they're leaving flash enabled on Silk, surely that dual-core chip is capable of keeping up with the bulk of browser rendering and js tasks.
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.
I'd say closer to Opera Mini, which pretty much runs everything through their proxy service. And I have to admit, it makes for a very compelling browsing experience on a phone - faster than any other mobile browser out there, with limited loss of functionality (ajax becomes a normal page turn instead of a local dom switch).
Isn't Opera Mini just a "web" client that always connects through Opera Turbo? Opera Mobile and Desktop, on the other hand let you switch Turbo on or off.
No, Opera Mini and Opera Turbo works a bit differently. While Turbo provides compression the actual rendering is always done locally. With Mini on the other hand the rendering is done server side, and then sent to the Mini client using an Opera Mini specific markup language.
I they were the same so I just Wiresharked Opera Mobile on my phone (with Turbo enabled) and it looks like you're right. My phone sends HTTP requests to something.opera-mini.net, then that server sends back compressed HTTP.
You must have a lot of Turbo/Mini proxy servers to handle all the clients. I guess it's against your TOS but I wonder how easy it would be to proxy another browser's traffic through Opera Turbo.
Is Opera Mini's format closed or is there a spec somewhere we can see?
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.
Even if they disable the MITM attack against SSL, or the conventional proxy, or the caching, the fact that browser internals can be shifted to their servers means they can get anything they want from your browsing session, including cookies and keystrokes.
Great, so if this thing becomes popular, the Government will be able to verify all that data and passwords at will, with just one phone call, like it happened with Wikileaks.
Not really. Automattic does a great job with Wordpress and keeping services online, no judgment of them.
For a company as large and successful as Amazon to launch a product on a default blog template under their ___domain? That's like launching a product on Blogspot, with that 'circles and dots' theme or whatever: it looks unprofessional.
Agreed, at first I just chalked it up to this be a "rogue" blog by some members of the team, but this page is the only "official" page I can find on the product. The favicon is even Wordpress...
Except Amazon's CDN and hosting resources dwarfs wordpress.com
I mean they aren't even using an amazon subdomain or their own ___domain - it all looks like an afterthought someone had this week "oh yeah we should have a blog, where can I set one up in a few minutes".
Their CDN and hosting resources may dwarf WordPress.com, but WordPress.com's main competency is keeping high-traffic blogs up and running nicely. There's no reason for Amazon to move into the blog hosting business, especially when you can get a custom ___domain and design on WP.com.
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.
No, not at all. I'm going with (hopefully) good parenting and crossing my fingers on that one. ;) It's preventing the "accidentally wandering into questionable content" that I'm interested in, in search results, etc.
I'm not so much even worried about protecting her from the "questionable content" because I think that's something she needs to learn to deal with (though we do of course have rules about what is and isn't allowed). I just don't want her stumbling across it on a tablet in her bedroom, where we won't notice and can't offer guidance or discussion.
We have a computer in the living room that she uses for internet access and we don't have any filtering software, etc. on it. It's just out in the open, so generally supervised.
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.
I’d like to hear more about what “facilitate” means.
Is the connection from the device right through EC2 out to the site secure, even from Amazon?
Or, is the connection from the device to Amazon secure, and the connection from Amazon to the site secure, but Amazon is acting as a man-in-the-middle?
Or, is the connection from the device to Amazon insecure, Amazon is acting as a man-in-the-middle, but the connection from Amazon to the site is secure?
I may be having a slow neuron day, but the wording of the FAQ doesn’t seem to definitively state which of these three cases holds?
It sounds like Amazon is a effectively a man-in-the-middle.
Hopefully the device-to-Amazon connection is secured by Amazon, but I can not find any details.
The privacy implications of all SSL traffic being decrypted on AWS are a bit scary.
I am guessing the end user will never see broken SSL certificate warnings (as you would expect in a regular browser), since Amazon can add a "Amazon MITM" root CA certificate to the browser.
If Amazon does, in fact, act as a MITM, then that's a deal-breaker as far as I'm concerned.
Edit: The more I think about it, the more I think it is likely that they are just passing along the connection. SSL is designed to prevent MITM attacks. They would have to provide their own certificate which would cause browser warnings. They could write their browser to ignore certificate problems for Amazon certificates, but that strikes me as a pretty gaping hole.
They're providing their own browser, so there's nothing that says this technique would have to trigger browser warnings.
It could easily work by having the connection between EC2 and the remote site be managed over SSL normally. EC2 then rejiggers the traffic, encrypts it over SSL with Amazon's certificate to send it to the device, and includes a little blob of data saying, "we got this from site X, whose certificate is Y". Amazon's browser could verify that but trust EC2 not to screw with the data. End result: no warnings, and your data is safe from everyone except Amazon. Which is not great, but neither is it hugely insecure.
What you say is very true, however when you say that SSL prevents MITM attacks, you are assuming that “their browser” always lives entirely within the device.
If their browser has code operating on the device and in the cloud, then their browser won't generate certificate warnings because there isn’t a man-in-the-middle between their browser and the site, there’s a man-in-the-middle between the device in your hands and the site.
It would be insecure against Amazon snooping or modifying the communication, but still generate the appropriate warnings about bad certificates.
I think the answer is, run “off-cloud” when you want privacy from Amazon.
Yes, I hadn't considered that possibility. The picture in my mind was some sort of hybrid operation where some of the work was offloaded, in which case you would still have to properly support device-to-site SSL links.
So I guess the issue of privacy still remains up in the air. I was hoping to be an early adopter of this, but I think I'll wait to see how the SSL via Silk situation pans out before putting down cash.
It sounds like they are using SPDY for the connection between the device and the cloud, so I believe that means that your connection to the Amazon server is secure. My reading is that Amazon will be able to see the secure traffic so that it can render it cloud side just like any other traffic. But the FAQ blurb is not a definitive answer.
My guess is everything is secure, but they are terminating the SSL connection, using a private cert to talk to the clients, and then passing along the information about the original cert. If they didn't do that, they wouldn't be able to optimize much since they couldn't read the content. They would also need a private IP address for every user (impractical), because the HTTP headers get encrypted as well and Amazon wouldn't know where to direct incoming traffic w/o using unique IPs.
a direct connection doesn't have a man in the middle. that's what direct means. amazon notices you're requesting an https connection and hops out of the way.
Both sentences in that FAQ answer are in direct opposition to each other and require clarification. But that hardly matters if Amazon has access to the browser's internals, anyway.
"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)."
So they are MITM'ing HTTPS connections.
"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.
So to me there's two parts of introducing new technology that every group has to address: the technical advances and the policy around the new technology for consumers. Amazon is obviously doing a good job to help the technical side of it, but so far I think they're failing on the policy. They haven't mentioned the ability to shut off the split processing or use a different browser, and the answers to their privacy FAQs on privacy on their website are totally evasive. I think they're going to find themselves in a world of hurt if they don't start being more open about their policies, but who knows, it may end up not mattering to the masses.
This is a temporary move, when 4G becomes widely available in a couple of years or even six months from now, in some countries web optimization via cloud computing will become a trivial.
But not so lazy that they couldn't install turn-key server software or a proxy that would do it for them. Much of it wouldn't necessarily require new standards, it could work using existing technology. For the parts of it that would require new standards, provided there is a proven reduction in latency, it seems like the win would more than make up for the expense of making a new standard.
-cheap devices (the fire?) get to see complex websites
-server side webgl?
-server side java applets?
Disadvantages:
-you partially browse the web on Amazon's cloud so Amazon can track your behaviour (and your data)
-your site is part of an internal network that can only be accessed using a vpn from the outside world? bad luck.
-you have to buy a cheap device to see a real pageload speed,considered that you should get your data from amazon anyway
-if the world uses ec2 for browsing its performance will probably suffer
if you have the ipad you can test a lot of similar apps anyway,like puffin or skyfire,and see if you would like it,I prefer the native browser myself,yet I know that the infrastructure would be better in theory.
A Wordpress blog running a theme from WooThemes. I guess we know we're dealing directly with the developers (but at least they listened to patio11's advice ;-).
I think this may be much more than Operas method. Note that it includes formatting, layout and display. This makes me think they essentially run a clone of the browser on ec2 and could literally swap in the completed Dom, and layout. Or even a a memory diff.
Having a persistent connection would also allow local events (clicks etc) to be sent back to mirror the state as you interact with the page.
Hmmm ... if they can reformat a 3MB JPEG to a 50KB JPEG on-the-fly, then they can also replace the ad that might have been placed on a site by the owner with one of their choosing. It would be interesting to see if there's a difference in click-through rates between Silk's user-agent and a traditional web browser.
As a kind of side point, I find it kind of interesting that Amazon is putting the EC2 brand front and center in this. You'd have to think it would be kind of surprising if they have really built it on exactly the same cloud that they are renting to 3rd parties - but that's certainly the way they are portraying it. It seems like they are almost trying to advertise EC2 to geeks as much as they are the Silk browser.
EC2 servers have massive computational power. On EC2, available CPU, storage, and available memory can be orders of magnitudes larger than on mobile devices. Silk uses the power and speed of the EC2 server fleet to retrieve all of the components of a website simultaneously, and delivers them to Kindle Fire in a single, fast stream. Transferring computing-intensive tasks to EC2 helps to conserve your Kindle Fire battery life."
What does this mean? "Transferring computing-intensive tasks to EC2 helps to conserve your Kindle Fire battery life". Are we offloading javascripting processing to the cloud and returning the results?
"Amazon has also added a few unique twists of its own that will further improve the user experience. An Amazon engineer at the New York launch event told us that the split browsing infrastructure can even compile JavaScript to ARM machine code on the server side in situations where it will provide a speed boost. He also told us that Amazon will track whether users prefer the full or mobile versions of various websites so that they can predict which one is better to send to users."
This seems sort of like CloudFlare built directly into the browser. Essentially, using EC2 as an http optimizing and caching proxy through which requests are routed. They might also geo balance traffic to the closest EC2 region.
Google also has a massive network of distributed servers and a couple browsers. I wonder if they'll start doing this for the Android browser and maybe even as an option for faster browsing on Chome.
Most tablet makers would kill to have this much developer interest. I'm fascinated by Silk and have wasted the better part of the day trying to figure out exactly what they're doing.
Here's an independent description of Silk behind the scenes:
The connectivity between the server and client side of Fire seems to be quite custom so it is unlikely a simple port. Amazon also mentioned that this is exclusive to Fire and made no mentioning of plan to expand Fire. If they do plan to expand Fire to other platforms in the future, I'd bet they mention it somewhere.
While I think the idea is brilliant - do as much precomputation and rendering and content consolidation in the cloud as you can - the strange thing to me is that all this stuff is really mainly a problem for browsing over cell networks while the Fire itself only supports Wifi. It kind of hints to me that there is a 3G Fire coming, they just aren't able to release it yet ...
Does it seem like Amazon is solving yesterdays problem instead of 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.
No, it is dynamic. In the video these sliders are actually moving. (And not static, as your image would suggest)
The article explains it like this:
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.
I wonder, in terms of having many connections, could the same thing be done by a HTTP -> SPDY gateway? It saves having a multitude of connections for a single request, and also is more compressed.
I don't think so. Amazon has a habit of using third party services for their blogs. This particular team may just have opted for WordPress.com, instead of TypePad, like they usually do (see http://aws.typepad.com).
Google picks up updates to sites hosted on Wordpress.com usually within minutes. Amazon registered the sub-___domain that would pull the most weight for the keyword term 'amazon silk.'
It's amazing how quick Google picks up changes to Wordpress.com blogs.
So, it's just an SEM thing. They'll probably have a post to the official channel soon.
This is what I was thinking, surely privacy becomes an issue if all of your data is going through what is essentially a 3rd party. Maybe secure connections bypass EC2?
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?