Ben Bucksch wrote:
Am I understanding that correctly that the component loads remote content with chrome privileges?
It allows you to set up an association (from chrome JS) of "xchrome://foo" to an arbitrary URI. Then loading "xchrome://foo" loads that URI with chrome privileges.
Note that it recommends using this with data: URIs, but yes, one could use an http:// URI. The main goal of this setup seems to be to generate some content on the fly, stick it in a data: URI, then load it as chrome. Or generate some content on the fly, register it, then later load it as chrome.
Think of this as a light-weight alternative to using XPCOM APIs to edit your extension's jar on disk to add new files, etc. ;)
I do have to agree that loading non-https remote URIs this way is problematic and the article should probably make this clear (and maybe the component should be changed to not accept such URIs).
Just to get around the RDF implementation limitations for remote XUL?
I don't see any mention of RDF on that page. Did I miss something?
In general (not this particular case, I've seen a number of other cases), I am very concerned about the Mozilla extension community.
You're not alone. -Boris _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
