Cade Metz, over at The Register, published an article on Monday about Amazon's requirement for authenticating API requests. He had called me over the weekend to chat, and we exchanged a couple of emails.
I think he wrote a fairly straight-forward piece, though my wife thinks his quote of my blog post made me sound a bit cold-hearted. Sorry, folks. You’ll just have to use a different search source. Yeah, maybe I could have phrased that better. And I actually think I can backport the implementation fairly quickly to the KDE3 version of Tellico. Just as soon as I get Tellico 2.0 out...
Like any internet article, some of the comments are insightful and some are confused. One accuses me of being a freetard/leech, one confuses application keys with Amazon Associates IDs, and then one guy says:
"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"
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.
I think this guy forgets what open-source means. Here's a hint, it means the source is open. Before the authentication requirement, Tellico used an Access Key, purely for identifying the request as coming from Tellico. It wasn't for security. Sure, you could argue that Tellico should have been requiring users to register for and obtain those keys on their own, from Day 1. In fact, I'll tentatively agree with you. But by far, the number of desktop applications that utilized the Amazon API, used the Access Key as a way of identifying the generator (application) of the request rather than the source (user) of the request.
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.)
I've been criticized at least once for including Tellico's Amazon Associate's ID as the default setting for HTML export and linking. And true, out of the box, all the Amazon links in Tellico use that ID as essentially, the referrer. But it's also one of the easiest settings to change, and was included as a config option for the Amazon data source from the beginning. In fact, you could have multiple Amazon sources, each with a different Associates' ID affiliated with it.
While the affiliate ID has not generated that much in referral fees, it shows that a significant number of people are browsing Amazon products that are linked from Tellico's HTML export. But maybe the comment writer does have a point. Now, with the requirement that each user provide a secret key, the onus for ensuring that Amazon's Terms & Conditions are met falls on the user rather than the developer.
If you're a Mac user, check out Delicious Library. Also notice that it doesn't give you the option of changing the exported affiliate code. And at first glance, their update to Delicious Library for Amazon's API switch doesn't appear to require a user-obtained key as Tellico does. Anyone want to argue that DL has, as its primary purpose, advertising and marketing the Amazon Site? I think that serves as pretty good corroborating evidence of the practices followed by Tellico...
But I do resent being called an open-source idiot! Just for the record...