On Tue, Aug 30, 2016 at 6:08 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> > Can you please clarify why this proposal is around preventing external > DLLs from using XPCOM? In my experience, a good number of the DLLs > different programs inject into Firefox are injected using the several > facilities that Windows provides for this task, and whether or not those > DLLs get access to the symbols currently exported from xul.dll, they can > still cause a lot of harm. I'm trying to understand how removing the > XPCOM functions they can link against dynamically will improve our > situation. > I'm working on that larger problem also. With the shipping of native messaging in webextensions, we may be able to make a policy that extensions and other addon-type software should not load DLLs into the Firefox process. I'm currently discussing the implications and implementation strategies of that with the addons team. This would however primarily be a policy and addon-signing question: we don't have a good way to actively block these DLLs. This proposal here is a technical step we can take which will immediately make things better. I've investigated several of the addon-related startup crashes that have caused us to delay or respin releases or block particular DLLs or addons over the past six months. Almost all of those crashes were related to the addon using XPCOM and being hit by some binary-incompatible change along the way. --BDS _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
