On 2016-08-31 9:27 AM, Benjamin Smedberg wrote: > > > On Tue, Aug 30, 2016 at 6:08 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto: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.
That sounds like a great idea! Especially if we end up revoking the signatures of add-ons which violate this policy. I'd be looking forward to see what comes out of that effort also. > 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. Makes sense. Thanks for the clarification! _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
