Importing an ASLR-disabled library into Firefox's address space makes Firefox significantly easier to exploit. Bug 642243 will help ensure Firefox itself contains only ASLR-enabled libraries, but on most Windows machines, Firefox's address space ends up with lots of third-party libraries.

Any idea what percentage of plugins and binary extensions this would wind up blocking?

It might not be so much the pct., but which high profile plugins need to be fixed before this happens. sounds like adobe reader is on that list still. maybe we could gin up a test pilot study or integrate something like this into breakpad to give us some hard data. http://scriptjunkie1.wordpress.com/2011/03/01/finding-non-aslr-or-dep-modules/

I suspect that it is not practical, given that this would affect all sorts of things which add themselves into Windows processes for good reasons, such as screen readers and other accessibility tools, IMEs, LSPs, and other things.

That makes it even more important to ensure they use ASLR!

Some of those things are very much wanted by the users who installed them (some not, of course). On my wife's laptop the graphics drivers are not ASLR, and they show up in both the firefox.exe process and a Flash plugin-container.exe process.

Maybe we can mine crash-stats to find the popular DLLs that lack ASLR. Getting them fixed will improve security for Firefox users directly, and make the change proposed in this bug more palatable. Filed bug 644763.

Bug 677797 is an alternative solution with fewer downsides.

For Win7 and Win8 there is now a way to let the OS enforce this in a way: http://support.microsoft.com/kb/2639308

Are there any plans to land this before / with sandboxing?

It looks like bug 677797 has morphed into a more general bug for "require ASLR, regardless of how". Let's use that bug.