For example, if your applet is designed to read a file from the user's hard disk on startup, the obvious place to invoke the necessary method is from the applet's start() method. However, in this case Explorer will protest with a SecurityExceptionEx[Host] exception.

Basically, when a signed applet attempts a "dangerous" action, the Microsoft VM looks back down the call chain, looking for a method that is either clearly "trusted" or clearly "untrusted". A method is trusted if it uses com.ms.security.PolicyEngine.assertPermission() to assert the desired capability. A method is untrusted if it has been called from the outside world (e.g. init(), start(), stop() or destroy()).

There is a way to avoid using Microsoft's security classes: instead of having your init(), start(), stop() or destroy() method perform the "dangerous" action, have it start a thread which in turn performs the "dangerous" action.

Someday, I may make this description clearer. Until then, check out this Microsoft article telling when you might have to use their proprietary privilege assertion classes: <http://support.microsoft.com/support/kb/articles/q175/6/22.asp>.

Next section: Signing for Microsoft Internet Explorer