XPConnect:Security:XPCNativeWrapper Automation

Notes on the new XPConnect security model

See bug 281988.

• Reimplement XPCNativeWrapper in C++ as part of XPConnect, in order to
  • wrap deeply, yet lazily
    • so that chrome authors don't have to (remember to) wrap parents, children, grand-children, etc.
  • automatically wrap content natives accessed from chrome
    • even less for chrome authors to (have to, therefore fail to ;-) remember
  • automatically unwrap when appropriate
  • preserve object equality in JS (== and != but not === and !==)
  • improve performance over the scriped implementation
• Optimize the chrome-accesses content test using JS engine changes
  • a new GCF_SYSTEM flag for objects
    • to distinguish chrome from content objects
    • using the one spare bit above the lock bit for objects
  • new JS_IsSystemObject and JS_IsSystemScript APIs
  • new JS_FlagSystemObject and JS_FlagSystemScriptFilename APIs
    • JS_FlagSystemScriptFilename allows the embedding to preconfigure script filenames as "system" (chrome, not content)
    • these filenames are pinned for the life of the JSRuntime
• Extend our extension model compatibly
  • support extensions sharing content wrappers
    • do not risk breaking extensions by imposing automated XPCNativeWrapper
  • allow app and extension files to opt into XPCNativeWrapper automation
  • this means a wrapper-sharing policy declaration in the chrome manifest
• Open issues
  • should "system" applied to a script mean has system principals, or wants system XPCNativeWrapper?
  • if so, we have enough bits, and IsSystemPrincipal checks can be optimized
  • if not, we need another bit, for wrapper sharing policy, per script filename (but not object) as opposed to a fast has-system-principals test