Rob Malda Casts a Jaded Eye at Amazon's Silk 143
m.ducharme writes "Slashdot's recently departed editor and Fearless Leader muses about the security implications of Amazon's Silk, which uses Amazon's massive cloud computing services to provide 'pre-caching' for the new Fire devices." Another potential downside to bear in mind (depending on exactly how much Silk relies on the AWS infrastructure) is that it provides a single point of failure, and sometimes cloud services go down.
Single point of failure (Score:3, Insightful)
Single point of failure? (Score:3, Insightful)
Well depending on how Amazon is using EC2, they could be doing the pre-caching in multiple zones so there may not be a single point of failure. But seriously, is this really a concern when:
1. The Kindle Fire screen, battery, PCB, etc are all a single point of failure
2. Your WiFi base station is probably a single point of failure
3. Your home cable/DSL modem is a single point of failure
4. The wires running between your home and the network POP is single point of failure
5. The DSLAM/whatever it's called in cable-speak is a single point of failure
6. etc etc etc
Yes, I know if you're using it at work you prolly have multiple WiFi access points and possibly redundant routers/connections to the internet, but why are you watching movies and playing angry birds at work?
Hell, the whole internet has gone down for large segments of the US due to construction workers/etc indiscriminately using backhoes to create huge fiber cuts, not to mention under sea cables being cut for various reasons.
I mean there's a lot of valid reasons why you may not want a Kindle Fire (I'm personally not interested in tablets at all), but I find this to be one of the weakest arguments out there.
Its all about the latency... (Score:4, Insightful)
This sort of structure for a web browser has huge potential latency savings.
Web pages consist of lots of pieces, from lots of places, and lots of dependencies. (Open up Firebug, open the HTTP console, and open up the New York Times to see). Latency is the huge limiting factor on page loads, and is why it takes 1.7 seconds for the NY Times to load for me, even though it only transfered 300 kB of data (which is only .12s on my Internet connection).
The Silk-style structure beats the latency bottleneck in two ways.
For NEW content, the Silk proxy is much closer to the content itself. If its just 20ms closer, that will still save 40ms for each dependent fetch from a different site, 20ms for each dependent fetch from an existing site.
And for content that Silk has CACHED, its even faster, shaving basically ALL latency off the fetch.
IT doesn't hurt that the Fire probably has too small a processor and too little memory to run a real browser, but the latency wins make this structure attractive even for real browsers.