Slashdot Mirror
Amazon's New Silk Redefines Browser Tech
angry tapir writes "While the Kindle Fire tablet consumed much of the focus at Amazon's launch event Wednesday in New York, the company also showed off a bit of potentially radical software technology as well, the new browser for the Fire, called Silk. Silk is different from other browsers because it can be configured to let Amazon's cloud service do much of the work assembling complex Web pages. The result is that users may experience much faster load times for Web pages, compared to other mobile devices, according to the company."
Opera was doing this YEARS ago. As usual.
Frist?
When you request a page in Opera Mini, the request is sent to the Opera Mini server that then downloads the page from the Internet. The server then packages your page up in a neat little compressed format (we call it OBML), ready to send back to your phone at the speed of ninjas on jetpacks.
You're missing the major difference between what Opera did and what Amazon is doing. Opera did the rendering on their own server, while Amazon does it in the cloud. Totally different.
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/ ).
So essentially, they become the man-in-the-middle so they can better cache your HTTPS content? And their browser is programmed to show this is acceptable/secure... What kind of privacy implications does this introduce? Even if their privacy policy says they won't use the data maliciously, cloud computing isn't a bullet-proof system (i.e., leaks, hacking incidents, etc.). Call me paranoid, but if I read this right, this sounds like a frightening idea.
You're absolutely correct that the basic "innovation" here is exactly what Opera Mini (note, not Turbo - specifically Mini) has done for ages. So all talk about "redefining the browser tech" is pure marketspeak, and both the submitter and the editor should be ashamed of spinning it the way Amazon PR wanted them to.
However, there is one crucial difference with Mini here: it also does work as a full-fledged local browser. Mini always does layout and other optimizations "in the cloud", and fetches the result. That's why it's so bad at JS, Flash, HTML5 etc - if it's something that has to run locally, it's not supported. Here, they are transparently offloading work on the server, but when there is something in the page that cannot be handled well that way - or when the server is not available - it gets rendered locally, same as in any other browser. So it's supposed to be completely transparent to the user, unlike Opera.
Of course, we haven't actually seen how well that it all works in practice, and I'll reserve my judgement until then. It'll be interesting to sniff traffic and see how much actually gets preprocessed; right now my suspicion is that on any script-heavy website, it'll mostly just do compression.
Speaking of optimization, you can save a byte with a small change to your sig.
Your sig assembles to: A1 00 4C CD 21 (5 bytes!) whereas:
mov ah, 4ch
int 21h
assembles to: B4 4C CD 21 (4 bytes)
Interrupt 21h won't care what's in al, so you don't need to clear it.
You kids these days code like everyone has megabytes of RAM just lying around.
Required reading for internet skeptics
Interrupt 21h won't care what's in al, so you don't need to clear it.
Well, whoever spawned the process in question might care, since AL is the return/error code after termination!
You kids these days code like everyone has megabytes of RAM just lying around.
I would have thought you old timers had learned your lessons about skimping on what you assumed to be unimportant bytes ;)
mov ax, 4c00h
int 21h