Amazon Silk web browser adds new twist to old idea | Hacker News Reader

Amazon Silk web browser adds new twist to old idea

arstechnica.com

43 pointsbbgm15 comments

As an engineer, I find myself intrigued and amazed by the design.

As a skeptic and privacy advocate, I see that this elegantly provides an unassailable technical justification for amazon to monitor, log and analyze 100% of all web activity that each customer engages in, developing fascinating behavioral and interest profiles on them. At least it can be disabled, for now.

Two major points: (1) It uses a single SPDY connection to the Amazon cloud. (2) It compiles JS down to ARM machine code.

Don't all JS engines compile to machine code these days?

If the special thing is cross-compiling to machine code on the server and sending binary code to be run on the client, then that might be new - but it's scary from a security perspective.

I'd like to see some evidence that transmitting ARM binary code of JS is faster than transmitting the original JS and then JITting it to ARM. The binary alone will be a magnitude larger at least than the original source.

Even if it's bigger over the wire, they might still save on total rendering time and/or battery life.

They seem to be suggesting that these optimisations are intelligent and vary with circumstances, so they don't have to work every time as long as they can predict when the right time to turn them on is.

Opera uses a similar approach for their Opera Mini mobile browser: the client is very thin and relies on Opera's own transcoding proxy to provide partially rendered content to the client. The problem of Opera Mini is it does not support true end-to-end encryption because the Opera proxy has to digest the content. I wonder if Silk has the same issue.

The rendering server is pretty much the definition of the man in the middle. I don't see how Silk could not have the same issue.

How much "Silk" load can Amazon handle without charging?

All of it. Right now it's only for Kindle Fire, and that device is primarily there just to sell the rest of their digital content.

How is this faster if Amazon is acting like a proxy and acting another layer of redirection?

By trimming all HTTP resource requests down to one SPDY request that hits a massive cached source on AWS, I can imagine it might be considerably faster.

By far the biggest win is probably replacing dozens of TCP sockets with one streaming connection for loading content.

After that, shrinking images, and maybe offloading some CPU (JS compilation, layout).

The "browser cache" story is less clear to me. Caching is an imperfect science. Some resources can't be cached, or the server doesn't it make it clear they can. On the other hand, the most "popular" resources may already be served by CDNs with very low latency compared to your wireless connection. Plus, does the iPhone really suffer from a shortage of cache? A shortage of RAM, sure, which is why tabs are frequently evicted, but how much cache do you really need? Safari on my desktop only has 180 MB in cache, which my iPhone could easily store.

1. Running some JS on the server 2. Recompressing images 3. SPDY 4. Better compression than gzip 5. Giant server-side caches

Also, I suppose the renderer will be smart about rendering it to the right dimension.. so on the client side, there will be way less calculation. I.e. Instead of trying to figure out if the next div goes on the same row or the next one, that will already have been calculated by amazon servers.

Caching and pre-rendering would be my guesses.

Reply on news.ycombinator.com