On content startup, scripts from a WebExtension can get executed in the content process via SendLoadProcessScript/RecvLoadProcessScript where a URI is passed from parent to child. The URI isn't a moz-extension URI despite being an extension script and therefore won't be remoted by Bug 1334550 "Proxy moz-extension protocol requests to the parent process". We'll need to remote these script loads in order to remove home directory read access for sandboxing.

Example content stack trace and URI: libsystem_kernel.dylib`__open+0xa XUL`nsLocalFile::OpenNSPRFileDesc(int, int, PRFileDesc**)+0x1e XUL`nsZipHandle::Init(nsIFile*, nsZipHandle**, PRFileDesc**)+0x33 XUL`nsZipArchive::OpenArchive(nsIFile*)+0x24 XUL`nsJAR::Open(nsIFile*)+0x94 XUL`nsZipReaderCache::GetZip(nsIFile*, nsIZipReader**)+0x27d XUL`nsJARChannel::CreateJarInput(nsIZipReaderCache*, nsJARInputThunk**)+0x135 XUL`nsJARChannel::Open(nsIInputStream**)+0xd7 XUL`nsJARChannel::Open2(nsIInputStream**)+0x32 XUL`nsMessageManagerScriptExecutor::TryCacheLoadAndCompileScript(nsAString const&, bool, bool, JS::MutableHandle<JSScript*>)+0x1a9 XUL`nsMessageManagerScriptExecutor::LoadScriptInternal(nsAString const&, bool)+0xc4 XUL`mozilla::dom::ProcessGlobal::LoadScript(nsAString const&)+0x63 XUL`mozilla::dom::ContentChild::RecvLoadProcessScript(nsString const&)+0x1d XUL`mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&)+0x8d70 XUL`mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&)+0x62 XUL`mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&)+0x156 XUL`mozilla::ipc::MessageChannel::MessageTask::Run()+0x4f XUL`nsThread::ProcessNextEvent(bool, bool*)+0x48f XUL`NS_ProcessNextEvent(nsIThread*, bool)+0x27 XUL`mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)+0x121 Here's an example where the URI points to the AddBlockPlus extension JAR/XPI file. (lldb) print url (const nsString) $18 = (nsAString = u"jar:file:///Users/haftandilian/Library/Application%20Support/Firefox/Profiles/kt4l38wb.ext/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/lib/child/bootstrap.js?0.6098366305192885&info=%7B%22addonID%22%3A%22%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D%22%2C%22addonVersion%22%3A%222.8.2%22%2C%22addonRoot%22%3A%22jar%3Afile%3A%2F%2F%2FUsers%2Fhaftandilian%2FLibrary%2FApplication%2520Support%2FFirefox%2FProfiles%2Fkt4l38wb.ext%2Fextensions%2F%257Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%257D.xpi!%2F%22%2C%22addonName%22%3A%22adblockplus%22%2C%22application%22%3A%22firefox%22%2C%22applicationVersion%22%3A%2255.0a1%22%2C%22platform%22%3A%22gecko%22%2C%22platformVersion%22%3A%2255.0a1%22%7D")

It turns out this won't happen for WebExtensions, but it's happening here in part because AdBlockPlus is not yet a WebExtension. Given that, the question becomes if allowing read access to $PROFILE/extensions (without read access to the rest of $HOME) is sufficient until we fully transition to WebExtensions. I'll take this bug for now to try to get that resolved.

This doesn't need to stay open. AddOns are dependent on being to read $PROFILE/extensions and we don't plan to remove read access to the extensions dir until legacy AddOns are no longer used.