On Wed, Jan 7, 2015 at 11:57 AM, Martin Robinson &lt;mrobinson@webkit.org&gt; wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Perhaps it makes sense that web extensions will need to rely on their
client programs to access resources outside of the sandbox. </div></blockquote><div><br></div><div>That works fine so long as the client program is written properly: the client must not trust the web process. That seems obvious, but it's inevitable that some application is just going to open() whatever the web extension asks for and not realize that this is dangerous. In contrast, an application author that grants the web process read access to the root directory knows full well what he's doing.</div><div><br></div><div>The other downside is that changes in the sandbox will be harder to manage. I want to prevent the web process from accessing the network (when the network process is enabled). If that happens, a web extension that, say, downloads adblock filters is going to break. Adding a URL to a whitelist is a lot easier for the web extension author than modifying the web extension to ask the UI process to load the URL.</div><div><br></div><div>The very considerable benefit, though, is that we don't have to add new API. We might try this at first, see how many complaints we get, and add API later if needed. No matter what we choose to do, changes to the sandbox will give web extension authors a hard time.</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">If we
allow disabling the sandbox or make it simple to expand it, I fear
that applications will simply switch it off, making their users much
less secure.</div></blockquote><div><br></div><div>This is also inevitable. I'm OK with making it mandatory.</div><div><br></div><div>How about an environment variable that gets checked only for debug builds?</div><div><br></div><div>Michael</div>