Updated on 2007-10-31: This change will be rolled back from Skype for Windows 3.6 gold. A different solution involving centrally managed whitelist and blacklist will be implemented as soon as possible. Read more about this new solution.

Following the outbreak of a worm that affected some users of Skype for Windows, we have decided to change the way applications get access to the public API the Skype client provides.

Presently, when a new application attempts to gain access to the public client API, Skype client presents the user a dialog box, allowing the user to choose whether to deny access, allow this time only, or allow this application to use the API from now on. The worm used the APIs provided by the Windows operating environment to send mouse clicks into appropriate places on this dialog, choosing "allow from now on" and closing the dialog before most users would even notice.

In order to avoid this, we've decided to start handling code-signed applications differently from these that are not. For applications that come with a valid code signature (e.g. Authenticode), the handling logic remains unchanged. For non-signed applications, Skype will not pop up a dialog box, but will raise a "missed event" notification instead. The user can then click on the event notification, open the access dialog, and decide what to do next.

This new logic is already implemented in internal test builds and will become available to the larger developer and user community when we release the next public beta version of Skype for Windows 3.6.

Additional changes are expected down the road. Please note that neither the timeline nor the exact nature of these further changes are not yet finally decided.

We are planning to make it possible for "trusted" applications to gain access to the public client API without ever requiring the user to explicitly allow them to do so (the users will still have an opportunity to deny such applications via the Options dialog if they so choose). "Trusted" will in this context likely include applications that we have evaluated and found to be reasonably safe.

The "reverse side" of this second change is that we'll be able to centrally blacklist applications that we have found to be harmful. Such applications will be denied access to the public client API, and the users will be notified via the events panel, so that they would be able to promptly react to potential malware infection.

We're also discussing the possibility that in future, a valid code signature will become a mandatory prerequisite for any public API access.

We believe that these changes benefit the end users and "good" developers alike. For the end users, this will definitely mean lower risk of becoming a target, or unwilling distributor, of malicious software. For the developers, it would probably mean increased willingness of the end users to try out various software that works with Skype.