Thanks for your answer. Boris Zbarsky ha escrito:
> 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. > I don't catch what you're trying to tell, I'm sorry. Could you explain it more? > > 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. > Ok, so there never will be a way to extend the javascript functionality, right? > > 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. > Yeah, but if my component offers a well defined set of services, i make the component react the way it wants, and you can make a extension that reacts when the page wants. I know it's not the same, but it approaches. > > 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? Ok, I knew from the beginning that this wasn't an easy thing. Even more, I really think it can't be done without starting from the beggining with a new model, so it's stupid to think about doing it, but I was just giving my opinion. Now I don't care about this, cause we have used an applet to solve the problem. It's just discussing for fun. This is another point, the applets. By default, all the policies are active, so if the user trusts the applet, it has full access. You can restrict quite well the policies, but it can only be done from the config file, manually, so I'm afraid that 99.99% of users around the world have very permisive policies in their Java VM. Why the security here is so relaxed? > 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"? Just like the ActiveX model. The problem with XPConnect is that you gain access to everything or you gain access to nothing, but not just what you want. And if you gain access you can only work with static web pages. This is a question I'd appreciate you could solve. In signed scripts, even the html page has to be signed and got into the jar file. ¿Why?. Which was the porblem with the model used till communicator 4 (having an 'archive' attribute in the script tag to refer the signature file for the script)? I think it's because you also want to certify the use it's done given to the script, but isn't that a huge level of paranoia? Understand me. We could be discussing this for a hundred years and nobody would have the point. It's only a point of view matter. I'm just a bit frustrated because this would have been an elegant sollution to our problem and it couldn't be. Of course, my opinion about mozilla software is still as good as before I started working on this. Thanks for your attention. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
