One consistent problem that we've had with the DLL blocklist is that it ideally needs to be initialized before user32.dll is loaded. This is necessary to prevent AppInit_DLLs, Windows Hooks, a11y hooks, etc from injecting DLLs prior to blocklist readiness. Starting with Windows 8, I think that we can relax this requirement while improving our blocklist coverage: 1) Observe that it's not the presence of user32.dll that we *really* care about, but rather its side effects (injection); 2) Those side effects may be controlled by SetProcessMitigationPolicy and PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY; 3) We are hesitant to outright block all dll injection due to its use by a11y, video drivers, etc.... BUT: beginning with Windows 8, we *can* set that policy temporarily until the blocklist has been loaded, and then disable it again, thus allowing us to be able to temporarily suppress user32-facilitated DLL injection until after the blocklist has been initialized. I see this as working as follows: 1) firefox.exe checks for the presence of user32.dll prior to loading the blocklist. 2) If user32.dll is already there, we need to restart ourselves by relaunching firefox via CreateProcess, setting a thread attribute list that includes PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY with ProcessExtensionPointDisablePolicy being turned on. 3) Once the DLL blocklist has initialized, we call SetProcessMitigationPolicy and disable ProcessExtensionPointDisablePolicy, this re-enabling injection.

Did we look how Chromium manages that?

Moving to p3 because no activity for at least 24 weeks.