Very informative series. Are you planning on putting this into an article on MDC?

(From Alex: Maybe, but probably not right away. My blog has several articles of this type that could and should be ported over to MDC, but I just haven't done it yet.)

any word on using SameOrigin? if you've got an exposed XPCOM component from an extension designed to interoperate with your web site, it would seem ideal to somehow set the "origin" of the XPCOM component to the URL for your web site and use SameOrigin access..

you might be interested to know of the statement made by Boris Zbarsky in this post: http://groups.google.com/group/mozilla.dev.tech.xpcom/browse_thread/thread/1d914272653ee02b/ef331f1dfe8868c9#ef331f1dfe8868c9

he says that implementing nsISecurityCheckedComponent and implementing nsIClassInfo are mutually exclusive -- that you do one or the other.

in my experience of trying to imitate your example, the nsISecurity* methods are never called if you've made your component a DOM_OBJECT ala nsIClassInfo.

so, your example produces an object which can be used from any web script without restriction.

(From Alex: Uh, oops. I did ask bz to review the third part of my series, but only the third part, so the subject never came up. However, the goal of the project was to create components which anyone could run. There should probably be some restrictions.)

I tried this approach, and it works great. Thanks, Alex. As posted by bz and others nsIClassInfo and nsISecurityCheckedComponent are mutually exclusive. I am facing another issue though, I'm unable to access properties or methods of return types that are XPCOM objects like nsIInputStream, or nsIDOMDocument. Do those need to be wrapped and registered with the categorymanager, just like the main XPCOM component or is there a shortcut?