Amazon API crackdown neuters book apps Following a change in the Amazon.com API, downloadable applications that rely on the etail giant for product data are experiencing a kind of Amazonian impotence. Nathaniel Elam, a Linux user from New London, Connecticut, recently encountered the problem with his copy of Tellico, a tool that keeps a digital catalog of his CDs, …
People that go to Amazon to get these things like album art (for music they already own) are basically stealing bandwidth from Amazon. While information was meant to be free, a company like Amazon probably pays a steep bill for bandwidth.
Amazon probably left the system wide open in hopes that people would dream up some novel new uses for the data that would also drive sales. But now if Joe Blow uses an application that invisibly gets the good stuff from Amazon, then Amazon is subsidising the application via its datacenter, and also getting no recognition for it (and also no sales to offset it.)
I won't go so far as to say "ha-ha freetards/leeches", but I probably could.
I expect that it won't be long before Amazon cuts all ties to the API in favor of an Amazon-owned and distributed application that will "lock" you into only getting information (ie, books, cover art, etc.) from Amazon if you *BOUGHT* the product at Amazon.
Apple has been excitingly successful with this concept (locking users into iTunes for EVERYTHING), and, if I were Jeff, I'd be wanting to scarf up some of that clout myself.
Shades of Scorpius - maybe we'll see the day that Google's ownership of the Galactic Library will become a GOOD thing!
I signed up for an Amazon API account - I made a little tool that allows people to price re-sale values on Amazon. I started getting bombarded with notifications of the change a couple of months before the cut-off. Then there was the every 1:x will fail unless they're signed. Can't exactly say this was an unexpected change.
Anyway, added the SHA sig and everything transitioned over smoothly.
Don't see why somebody couldn't just setup a proxy for the OpenSource community (OK, it might break a few T&C, but not exactly 'bad'). Proxy picks up request, hands it off with signed sig, stores returned XML and caches for next x-days. I assume most of the requests these open-source requests are for are for static data (art, track listings etc - rather than up to the minute re-seller prices).
Have you used iTunes? Ever? The only 'tie' I see is if you purchase m4p audio content from Apple then you'll need iTunes to play it (if it is DRM'd - otherwise its a snip to convert to MP3). If you don't want that, then don't buy DRM'd content using iTunes.
Granted you can only sync the iPod Touch and iPhone using iTunes, but even then, media can come from anywhere as long as the format is supported.
That said I don't like the idea of the alleged forthcoming tablet being locked down in the same way as the phone, that would turn me right off. Its the wrong way to go - you'd think Apple had learnt the lesson with the iPhone
"Tellico had the same key. It was hard-coded in the source."
Rather shoddy coding practices on display there, me old mucker.
"Some other application could have used the same key, since it was pretty much public, though"
What?!?!
I can see this being the driving motive for private keys. Amazon are allowing these (non-profit generating) database queries out of good will, despite these apps clearly being in violation of the T&C (you're not going to purchase a book or album from Amazon, which you're software has just catalogued you as clearly already owning.)
If sloppy security practices are allowing other apps to spoof their identities, then I can easily understand that, at the very least, this would create a nightmare auditing the traffic load on your database.
At worst, I could see this potentially being used in some nefarious fraud technique. I suspect these freebie apps aren't the only ones using the services - I wouldn't be surprised if there are some people paying to use this service too, with some form of per click revenue generation.
And if there aren't, I'll wager Amazon may have plans to.
If you're an administrator, then you'll be wanting to keep close tabs the server load which you're shouldering out of sheer generosity, so it’s of no surprise that they’ve clamped down on security if these open source idiots have been handing out their security keys willy-nilly.
The API provided convenient access to data that Amazon already provides public access to, through their HTML interface.
It is a convenience to automated consumers of that data to have it accessible in an API, and likewise I'm sure Amazon would prefer automated access to avoid needing results to be rendered to HTML, at a bandwidth and processing cost to themselves.
Unfortunately, as they've decided to block public access to the API, the only public access is now through the HTML interface. So, we'll go back to accessing it through that, parsing the html returned to scrape the data we need and discarding the rest.
At least one album art downloader has already updated to retrieve Amazon cover art this way.
"What do you mean "What?!?!" ? It's trivial to use Wireshark (etc) to sniff API calls... this should not be a surprise to you."
I think he was referring to the ethics of just plugging someone else's key into your own stuff. Although I daresay he and I are surprised about you bringing sniffing into it when *you can get the key from the source*. I thought all you open source gimps read the source code as a matter of course, since no-one else can be trusted to write a trustworthy and/or stable app? Sheesh.
Nope, the likely problem is that at least some of the cover art and pictures are not licensed for reproduction anywhere besides the amazon website. By allowing apps to pilfer the content unimpeded Amazon puts itself into a position of assisting an infringement or infringing on copyright.
I use the AWS APIs (and the apps I coded were unaffected by this as they require users to provide their own keys - Amazon made clear for ages in advance this minor change was going to happen). If someone finds the functionality useful enough they will be prepared to get keys from Amazon - it only takes a few seconds. The change is quite subtle anyway - main public key the same, just requires an extra secret key, and really no major hassle code wise.
My apps always used the users own keys as the whole idea of AWS affiliates is that click throughs (with id encoded in urls) that lead to Amazon purchase give the affiliate a tiny cut of that sale - lots of sales via Amazon gives nice cash reward: My customers want this cash for themselves - they do not want my keys earning me money via lots of micro-payments.
The AWS T&Cs - if you bother to read them, are very restrictive - when I last checked the images and other information can be cached for no longer than 24 hours and long term storage is totally forbidden: So the apps I produce get data dynamically and do not store it: Another benefit of using users own keys is that, if someone uses my apps and takes a long term copy of the data my app dynamically serves (violating T&Cs) then that is their breach of contract with Amazon and their legal responsibility.
However just about every other app I have seen that uses AWS breaches the Amazon T&Cs - but Amazon seem to take a very relaxed attitude, this change does not prevent that abuse.
Apps that did uses a single key for many users were at risk anyway - there are (quite low) usage limits (unless you apply to get a more "pro" account where restrictions are far less) and using same key in a widely distributed app could have meant calls fail (although from my testing it seems Amazon never really enforce the non "pro" limits - using test accounts I have exceeded the 1 call per second limit and daily call limit without problems).
Anon as commenting on an area I work on occasionally.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
