This is a personal tumbleblog, intended for random musings and snippets. I have a somewhat more structured travel and photo blog at disoriented.net, and a neglected vanity site at raingod.com.

Posts Tagged: Amazon

It's time for a unified ebook format and the end of DRM

Joe Wikert calls for platform lock-in and DRM-encoded ebooks. I agree with everything he says, but I don’t see the situation changing any time soon.

Stanza's swan song

The popular ebook reader, Stanza, has now been updated for iOS 5, but new owner Amazon says that this is the last update.

I stopped using Stanza, formerly my reader of choice, because it was unusable on iOS 5. In its place, I started to use Apple’s iBooks, which turns out to be a remarkably capable and polished reader. I’m downloading the new Stanza update, but I’m not sure I’ll go back to Stanza.

EFF Gets Straight Privacy Answers From Amazon About New "Silk" Tablet Browser

The Electronic Frontier Foundation has got some answers from Amazon about possible risks associated with the Silk browser technology. The responses are fairly encouraging: it sounds as if Amazon has thought about the issues and tried quite hard to respect user privacy.

Text

There’s lots of excitement today about Amazon’s new Kindle devices, including an inexpensive tablet running Android. Most of that excitement focuses on the price point, but there’s something in the announcements that may be even more significant.

Amazon’s new devices will ship with a new web browser architecture named Silk, which Amazon describes as ‘cloud-accelerated’. What they mean by that is that Silk browsers will use Amazon’s EC2 essentially as a giant caching proxy. The company says that “many website requests will never leave the extended infrastructure of Amazon Web Services”.

The stated goal is to improve the user experience by delivering pages faster. But ‘cloud-acceleration’ also creates an entire class of users - which, given the aggressive pricing of the Kindle devices, is likely to be a large class - who will access the web through a chokepoint controlled by Amazon.

What are the implications? The first, for web developers, is that you need to pay close attention to anything in your configuration that affects caching, such as Cache-Control headers and ETags. Get it wrong, and Amazon will cheerfully serve up stale content to all its Silk users. It’s a rule of thumb when you’re writing a complex web app that each layer of caching can be a generous source of hard-to-understand bugs: Amazon’s new scheme has just dropped a giant layer of cache between you and a large number of users.

We’re assuming, of course, that Amazon will play nice and honor the cache control directives you provide, of course. But Amazon is also theoretically free to introduce some ‘optimizations’ of its own that could inadvertently cripple your site. Suppose the Amazon cache has a rule that says that if it doesn’t get a response from the remote server in 15 seconds, it falls back on the last cached version. Now suppose that your complex dynamic page takes 30 seconds to respond. In the best case, users are going to see a stale version of your page about half the time. Or if Amazon just imposes its own limit on the number of times per minute it goes to your site for new content, similar problems can arise. Amazon is likely to be careful not to do anything that will affect popular sites, but smaller producers may get shorter shrift.

At this point, there’s no reason to think that Amazon won’t obey established rules for making proxies behave correctly, so these scenarios may never arise. The point is, however, that if Amazon does decide to implement any shortcuts for its own convenience, or for the perceived convenience of its users, it’s going to affect a lot of people.

Let’s get back to that chokepoint. What can Amazon do with it, aside from speeding up your web access? Well, the answer is ‘Pretty much anything’. At a stroke, Amazon has gained access to a giant chunk of information about how people use the web. It can see which pages are loaded, which links are followed, how long users spend on each site and how often they go there. It can ‘discover’ pages that would normally be hidden. It can track associations between different pieces of content - how likely visitors to site A are to also load site B - and use that to develop a web recommendation engine similar to the one already used on its shopping site. In essence, Amazon has just joined the big boys - Google, Microsoft, Facebook - as a member of an exclusive club of companies that have a panoptic overview of how the web is used. If you think that this isn’t part of the gameplan and that Amazon hasn’t made plans to leverage all the data it can now access, you’re dreaming.

It needn’t be limited to aggregate information, either. Kindle devices are set up to facilitate buying content from Amazon - like Apple’s iTunes, they’re as much about giving you easy access to the company’s store as they are about giving you access to the media you own. So the device knows who you are, which means that Amazon could make the connection between your Amazon profile and what you do on the web. Will Amazon make use of that information? In the short term, the most likely impact will be on your recommendations in Amazon’s webstore. But the temptation for Amazon to store everything for future use is going to be very strong.

The chokepoint represented by Silk’s ‘cloud-acceleration’ also opens the door to some real nightmare scenarios. One is that any collection of information about your browsing activity that’s held by a third-party is potentially open to attack. If Amazon does collect and store this data, they should regard it as being at least as confidential as payment information, and secure it accordingly. But corners get cut and perfect security looks increasingly like a pipedream. Sooner or later, some of that information is likely to leak. There’s also a risk of other information leakage. If Amazon does apply collaborative filtering to your web activity and use it to drive a recommendation engine, it’s not going to be long before they end up recommending pages that shouldn’t be public or URLs that insecurely encode user credentials (and yes, webmasters shouldn’t be putting credentials in URLs, and anything that you want to stay private should be behind access control - but, as I said, corners get cut).

If Amazon wanted to be truly evil, there’s a lot more that they could do. Actual censorship and on-the-fly replacement or insertion of content or advertising are just two of the possibilities. Similarly, if Amazon’s security fails to hold up and someone gets access to their servers or executes a successful DNS spoof, third parties could make use of that single point of access to perform some of the same tricks.

For Amazon, ‘cloud-acceleration’ through EC2 offers some major new business opportunities. For users of their devices, it offers a small amount of convenience and some potentially significant new risks.