Living in a Go Faster, post-XUL world
eshepherd at mozilla.com
Wed Jul 15 02:51:16 UTC 2015
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. :)
Senior Technical Writer
Check my Availability <https://firstname.lastname@example.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev