Hey marrethozi,
You're right that we need to handle request slightly differently from Flickr. The consideration is that we want applications made to work with flickr to work with 23 without you needing to rewrite code. And since Flickr controls the register of secret keys, this leaves us unable to verify the api_sig parameter.
What the api_sig parameter does, however, is one thing: It verifies that the api key is correct -- and thus that an application matches the records over on flickr.com. It verifies to Flickr that the application is approved and not masquerading as another application.
However, for any desktop application, the secret_key can be extracted from the application, which is even easier if the app is open source making for a false sense of security. Only for web applications that use the Flickr API is secret_key secret at all.
Thus, from a security standpoint, 23's implementation of the Flickr API is just as secure as Flickr. The only difference is that we are less able to verify the identity of applications, which only affects our ability to gather statistics, not any security-related aspect of the user's interaction with 23. (It could also affect our ability to block certain applications from using our API, but Flickr's ability to do so is also hampered by the fact that many secret_keys cannot be kept secret.)
You're right, of course, if somebody were to pick up the auth_token they'd be able to access your photos -- but the exact same thing is true of that same someone were to capture your browser cookies or your username/password which are also sent in plain text by browsers. This leave our api no more and no less secure than the ordinary site or any other non-https website for that matter. And the same thing would be true if you used Flickr.
(There are ways to make the API more secure, but we wish to maintain compatibility with apps that support the Flickr API. We feel, however, that the current API provides a reasonable amount of security for the purpose.)
I hope this clarifies the issue ;-)
