Monday, October 12, 2009

The Secret About Amazon's API it Doesn't Want Distributed

Amazon's Product Advertising API (PAA) lets you search pretty much everything they offer. But on August 15 they started requiring that all requests to the API be signed with the developer's Private Key. Any client-side software using the PAA directly, including website scripts, Firefox extensions, and desktop applications, would have to distribute their Private Key to all their users to sign the requests. But as you would expect, the license agreement for the API states
a private key...is for your personal use only and you must maintain its secrecy and security.
Others have written about how the PAA license agreement bars its usage on mobile devices. But in fact, it bars it from any client-side software on any device. Or at least from software you want to distribute. You can work around this by hosting a server to sign requests for your users, keeping your Private Key private. But anybody could use your service, pretending to be your client software if necessary. And you could wind up signing requests for half the Internet. The signing requirement benefits nobody. It impedes developers, turning them off from creating applications to serve users and send customers Amazon's way. Amazon should acknowledge its mistake with this policy and reverse it. Thanks to James Vasile for reading drafts of this.

12 comments:

  1. I think it might be a push to consolidate the number of requests from unique sources. By that I mean, making developers host the application that uses the API. By doing so amazon's tracking may end up being more robust or just easier to handle. Ok the xyzamazonapp sent us 44k hits today. That sort of thing. Instead of a multitude of users which amazon might know nothing about. I think this is a step to make their data more useful by constraining the way in which their product is used.

    ReplyDelete
  2. Easy to deal with, just make the end user enter their own keys rather than distributing yours. It's easy and free to sign up for an amazon account to get the keys.

    ReplyDelete
  3. This reminds me of the developer keys that were made available for mucking with google APIs a few years ago. The real reason for the keys is to associate a set of API traffic with your developer license and/or email. It provides a convenient way for Amazon to throttle or even disable access to their service from a misbehaving outside party.

    Setting up a webserver as a proxy may only work if the service remains unpopular.

    ReplyDelete
  4. You could sign requests to your server service with your own key, then have the server's request to Amazon sign the request with your developer key. Then you ensure your service is private and comply with their T&C.

    ReplyDelete
  5. Err, why not just throw together a quick rails app (or w/e) that serves as a webservice for your app to use, and keep your PAA key local? The service could even be simple...just "send me a params list and I'll sign it and return it" so you didn't have to change app functionality.

    Open source it, and everyone that also has this problem can use it. Should be able to knock that together in an hour tops...so what's the beef?

    ReplyDelete
  6. (Also, require auth from your app)...figured that was a given but might as well be explicit.

    ReplyDelete
  7. I think some of you misunderstand something. If you host a server to sign requests for your app, there is no way to use that server from your client-side application without people being able to reverse engineer it (assuming you bother to do some kind of auth or obfuscation) and use your server as well. Sure, that's probably still an option (if you're willing to take the risk of getting cut off b/c of those unofficial users), but the point remains: it's a barrier to development and serves no purpose.

    To the people talking about how Amazon can tracks things better this way: no, they really can't, since anybody can freeride as described above.

    ReplyDelete
  8. Well, the free-riding problem only occurs if there is no authentication between the app. and its server. I think Amazon want developers to authenticate their users to prevent abuse.

    ReplyDelete
  9. @quanticle: Yes, but any authentication a client-side app is doing can be reverse engineered/broken.

    ReplyDelete
  10. @Gabriel Burt

    The authentication can only be reverse engineered if each app has the same key. If, for example, the developer forced users to make accounts with the service, and then only forwarded requests from users that had authenticated themselves, reverse engineering would not be a problem.

    I think Amazon wants to distribute the job of patrolling spam/spurious API requests to the developers that use the API, rather than doing it in-house. The penalty for not doing so would be having your key revoked, of course.

    ReplyDelete
  11. @quanticle: Ok, fair enough - if you force users to have an account to use your app, then it could work. Yet another impediment and deal-breaker for many developers.

    ReplyDelete
  12. @Gabriel: "Yes, but any authentication a client-side app is doing can be reverse engineered/broken."

    If it were so easy, then why hasn't the authentication in the DAAP protocol been broken yet?

    ReplyDelete