<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><span>David
Rajchenbach-Teller wrote:</span><br>
<blockquote cite="mid:55A3D550.5090705@mozilla.com" type="cite">
<pre wrap="">Well, I don't think sandboxing is an issue. But fair enough, let's make this</pre>
</blockquote>
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<br>
<ul>
<li>"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).</li>
<li>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.</li>
<li>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.</li>
<li>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".</li>
<li>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.</li>
</ul>
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. :)<br>
<br>
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. :)<br>
<br>
<div class="moz-signature">-- <br><br>
<span style="font-weight: bold;">Eric Shepherd</span><br>
<span style="font-weight: bold;">Senior Technical Writer</span><br>
<a href="https://www.mozilla.org/">Mozilla</a><br>
Blog: <a href="http://www.bitstampede.com/">http://www.bitstampede.com/</a><br>
Twitter: <a href="http://twitter.com/sheppy">http://twitter.com/sheppy</a><br>
<a style="font-style: italic;"
href="https://freebusy.io/eshepherd@mozilla.com">Check my Availability</a><br>
</div>
</body></html>