I know a lot of DOM folks hate the compartment API and a lot of JS folks are sad that the DOM folks hate it, so I'd like to offer an alternative perspective here.
I think the strictness of the compartment API is awesome, because it gives us insanely powerful security invariants. There are so many games of sec-bug whack-a-mole that we don't have to play because we know definitively that: 0 - The object principal and subject principal can always be deduced from the associated compartments. 1 - Objects cannot reach cross-compartment objects without going through a cross-compartment wrapper (and thus receiving a security audit from XPConnect). 2 - Script from a given page can only operate directly on objects from that page. (Cross-compartment references go through wrappers, as above) 3 - When C++ operates on the JS objects it hast to enter their compartment, meaning that "system credentials" ([System Principal] or a nullptr principal) can never leak into JS. Even if JS tricks C++ into entering script via evil getters or whatnot, the subject principal is _always_ the same as it would be if that script were being interpreted normally. Now, the flip side of this is that same operations that could have potentially violated the above invariants now manifest themselves as compartment mismatches. But I contend that this is much better than the alternative, because compartment mismatches are obvious, instantly fatal, and nearly always easy to diagnose and fix. In the old world, we'd have to wait for clever security researchers to notice mismatched invariants, find a way to exploit them, and then hopefully report them to us. I contend that most compartment mismatches we find today would have been security bugs in an analogous compartment-less world - we just wouldn't have discovered very many of them. I think these invariants are extremely important, and I haven't thought of a way to make them happen without callers being minimally aware of them (in the sense of 'enter a compartment'). I've pondered having the JSAPI methods automatically enter compartments, but that's kind of sketchy. Moreover, if such checks were acceptable performance-wise, then I think we should just make compartment checking run on release builds (so that we could just MOZ_CRASH safely, meaning compartment mismatches would no longer be security bugs). Does anyone have a sense if that's in the realm of the possible? bholley On Wed, Nov 21, 2012 at 8:34 AM, smaug <sm...@welho.com> wrote: > Hi all, > > could we somehow make compartment handling less error prone. > We've had tons of compartment mismatch bugs and that is rather clear > indicator that the API itself is either too difficult to use, or too > easy to forget to use, or both. > Hopefully with Paris bindings JS API usage will be codegenerated in more > cases than > currently and that will lead to fewer bugs, but no doubt there will be > still > non-codegenerated JS API usage in Gecko. > > > > > > -Olli > ______________________________**_________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@**lists.mozilla.org<dev-tech-js-engine-internals@lists.mozilla.org> > https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals> > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
