Mitchi wrote:
Look at how window.sidebar and window.XMLHttpRequest and friends work.
You don't need to require things to be signed.

Sure, but these are part of the DOM, and accessing them is not so
critical.

You missed timeless' point. His point was that your component can attach hooks to the global JS object allowing untrusted content to call into your component and only your component. That's what XMLHttpRequest does.

The problem is that XPCOM is a very powerful way to let developers
extend mozilla's functionality, but the strictness of the access method
makes it completely unusable.

It's not really designed for use from web pages, yeah.

should be trusted just by letting its instalation (signing the
component, not the scripts), the same way is done with the extensions.

Sure.

I mean, You can install an unsigned firefox extension (most of them are
unsigned), and they could be as harmless as my component (The only
difference is that the extension is activated by an event, but it's
really easy to make it react to a structure on the document loaded).
¿Why the extension can work freely and my component has to be accessed
by signed scripts and static html docs packed in a jar?

In part, because the extension is reacting when _it_ wants to react, whereas you want a scenario where the component reacts when the _page_ wants it to react. So there's a major difference in control flow.

The answer is that, installing an extension provides just this
functionality

Not strictly true...

but giving universalXPConnect access lets you use every
scriptable component, even the critical ones.

Right.

So, I belive that the access model should be different, letting you
gain access to just a component, not to every one.

Care to write up a proposal for how this should work, exactly? That is, how does one know which scripts should be allowed to instantiate which components? Or are you saying that components should have an easy way to say "allow me to be instantiated by all scripts"?

-Boris
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to