XPConnect:Security:XPCNativeWrapper Automation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
Notes on the new XPConnect security model [https://bugzilla.mozilla.org/show_bug.cgi?id=281988 bug 281988].
== Notes on the new XPConnect security model ==
 
See [https://bugzilla.mozilla.org/show_bug.cgi?id=281988 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" mean has system principals, or has system XPCNativeWrapper?
** if so, we have enough bits
** if not, we need another bit, for wrapper sharing policy, per script filename (but not object)

Revision as of 20:37, 17 May 2005

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" mean has system principals, or has system XPCNativeWrapper?
    • if so, we have enough bits
    • if not, we need another bit, for wrapper sharing policy, per script filename (but not object)