Living in a Go Faster, post-XUL world

[Eric Shepherd]

David Rajchenbach-Teller wrote:
> Well, I don't think sandboxing is an issue. But fair enough, let's make this
I think you can come up with a phased sandboxing solution; that is, you
can use a permissions-based mechanism by which code that is signed and
authenticated can access core Gecko stuff in ways that other code
cannot. You could even potentially have something like

  * "Add-ons" which are signed by Firefox-Core (or whoever builds and
    signs the application for distribution) and bundled into the app at
    build time can touch anything they want to; the trade-off, however,
    is that these cannot be updated out of band; the application
    requires a full update (since the entire package including these
    add-ons are signed together).
  * Add-ons which are signed by Firefox-Feature (or whatever you want to
    call it) are not part of the core application like the ones above,
    but by virtue of how they're signed and the permissions granted to
    that key have access to a vast swath of internals that typical
    add-ons don't need access to.
  * Add-ons which have been signed and have gone through AMO
    certification have access to the next tier of internals. They can
    access a lot of stuff that the serious add-ons need to be able to
    get at, but not the really deep internals of Firefox that they
    should avoid. This layer of access might include APIs that grant
    partial access to deeper levels of Firefox in a controlled manner.
  * All other add-ons have no access to Firefox internals of any kind,
    and only function in DOM space and whatever areas of Firefox's UX
    are deemed "safe".
  * You might have one more tier of signed add-ons which have limited
    access, or even types of signing and permissions which allow them to
    be restricted in various ways. Some of this depends on what we're
    willing to invest both in Firefox and AMO.

If we're going to do this massive a change to how Firefox works, I
applaud any efforts we make to do it right; better to take our time and
do a good job of it than turn it into a disaster. :)

I'd also love to encourage y'all to ping the Developer Relations and MDN
teams any time you have thoughts that might benefit from being bounced
off people who arguably spend the most time directly interacting with
add-on developers. Not to mention that we're the ones that will have to
explain whatever you decide to the community. :)

-- 

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshepherd@mozilla.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20150714/66be72c1/attachment.html>