64-bit browsers are more stable and more secure; Mozilla should build one.
The stable, supported, mainstream version of Firefox on Windows is a 32-bit application. Even if you use 64-bit Windows, if you use Firefox, you're using a 32-bit browser. The exception is if you're using the Nightly build of Firefox. This represents the latest, cutting-edge version of the browser, and it's available in two versions: a 32-bit one, and a 64-bit one.
However, this won't last much longer. Mozilla announced last week it was no longer going to produce 64-bit Nightly builds of Firefox for Windows; nor will it run automated tests of 64-bit Firefox. The browser's future on Windows is resolutely 32-bit. Linux and Mac OS X, in contrast, both have official 64-bit versions.
Several reasons were given for this discontinuation: many plugins have no 64-bit version, Mozilla's bug reporting and tracking infrastructure provides no clear distinction between 32-bit and 64-bit problems, bugs go unfixed because the 64-bit Windows version is not deemed a priority, and JavaScript performance in the 64-bit builds is substantially slower than in the 32-bit version. Further, Mozilla developers say they won't fix any bugs that only manifest in 64-bit versions. Firefox developers say a fully supported 64-bit version of Firefox won't be released in the first half of 2013 and it probably won't make the second half either.
This is an unfortunate decision by Mozilla. 64-bit support is not important to all applications, but when it comes to Web browsers, it has a valuable role to play. At its core, the difference between 32- and 64-bit comes down to memory. Each 32-bit process gets 232 bytes (that is, 4GB, of memory to use). Each 64-bit process gets 264 bytes, 18EB, four billion times more memory, to play with. Of that 4GB that 32-bit processes can use, there's a further limitation: 32-bit Windows reserves 2GB or 1GB for itself, giving each 32-bit application only 2 or 3GB to use. 2GB is the default; to get 3GB, the application needs to opt in, and Windows needs to be booted in a special mode. On 64-bit Windows, 32-bit applications that opt in to 3GB support actually get almost the entire 4GB to themselves.
64-bit security
Why does memory matter so much for browsers? There are two reasons. One is common to all browsers; the other is more specific to Firefox. The first reason, the universal reason, is a little thing called security. Security flaws in browsers are an unfortunate fact, so operating system and browser developers both implement various features to try to reduce the impact of these security flaws. For example, one could run the browser in a low privilege sandbox so that malicious exploits cannot easily write to the user's hard disk.
One of these protective measures is called Address Space Layout Randomization, ASLR, and it works by moving DLLs and application memory into unpredictable locations within the 4GB that each 32-bit application has available to it. This makes exploitation harder, but on 32-bit systems the protection is limited. With only 4GB of space, there aren't that many random locations to choose. DLLs, for example, still need to be packed relatively close together, to ensure that there are large tracts of free space open for applications to store their own data in.
This lack of randomness is compounded by the fact that these days, 4GB just isn't that much memory. Filling all the memory with data that the attacker controls is now feasible. In a process known as heap spraying, attackers fill the victim application's memory with large blocks of code that do nothing, followed by their exploit code. This gives attackers much greater flexibility: instead of having to work out the exact memory location of their exploit, they just have to be somewhere close. As long as they find a location in the "do nothing" block, their exploit will run correctly.
In the world of 64-bit, this all changes substantially. With 18 exabytes (theoretically; real processors impose tighter constraints) of memory, there's plenty of room to scatter DLLs liberally making them needles in an unimaginably large haystack. A new Windows 8 feature called "High Entropy ASLR" does precisely this. The vast amount of memory also prevents any realistic attempt at heap spraying—the amount of memory is too large, and the amount that an attacker can fill up is too small.
For many applications, the stronger security provided by HE-ASLR and 64-bit computing probably isn't hugely valuable. As a practical matter, most applications have little meaningful exposure to the kind of attack that ASLR and HE-ASLR are meant to hinder. But Web browsers are a huge exception to this: they're huge vectors for malware, because they're routinely used to connect to networked resources that are beyond the control of any end-user.
Browsers need all the security mechanisms that developers can throw at them, and by sticking with 32-bit code, Firefox is unable to take advantage of some of the security features that Windows 8 has on offer.
64-bit stability
About time we mentioned there were two main issues with 32-bit on Firefox. That second problem is specific to this OS: Firefox is getting too big for a 32-bit memory space. Firefox does opt in to using 3GB of memory if it can, and 4GB when run on 64-bit systems, but this isn't enough. Except for plugins, everything Firefox does has to run within a single process: every tab you have open, every Firefox window you have open, every image, every script, every download, they're all sharing 4GB of memory. With lots of tabs—or complex pages and scripts, or even bugs within Firefox itself that cause memory to be allocated but then never freed when it's no longer needed—that 4GB can run out. As you approach the limit, Firefox gets slower and slower, as it has to work harder to make more memory available. Eventually it runs out, and typically, it crashes. (This limitation was one of the big reasons I switched back to Chrome, in spite of my preference for Firefox's appearance and interface.)
64-bit Firefox, by virtue of having so much more memory available, would essentially never run out of memory.
Mozilla is working to alleviate the issue somewhat. Since version 13, Firefox already has on-demand loading of tabs: restart the browser and any tabs that you don't look at don't actually get loaded, saving memory. Mozilla developers are also planning a feature that would unload tabs you aren't currently using, again making more memory available. But these are both stopgap measures. These are of little assistance when tabs legitimately require lots of memory, or when multiple tabs are in regular active usage.
A robust solution to this problem does not strictly require the use of 64-bit. Chrome on Windows is also a 32-bit browser (though there is some effort underway to produce a 64-bit version), but because Chrome strives to have one process per tab, the resource constraints are much less acute. Instead of having to fit everything within 4GB, Chrome only needs to fit a single Web page within 4GB. Different tabs each get their own 4GB to operate in. This doesn't offer Chrome the security benefits of using 64 bits, but at least prevents it from running out of memory.
Mozilla once embarked on a project to bring this kind of capability to Firefox. It was called Electrolysis, but the project has been all but cancelled. It's unlikely to offer salvation any time soon.
Opera, which shares Firefox's mostly-single-process design, has a fully-supported 64-bit version, so like Chrome, it too avoids the resource constraints. Unfortunately, Opera does not support HE-ASLR and so does not take advantage of all that 64-bit has to offer.
Internet Explorer has a multi-process design (indeed, it was the first mainstream browser to use such a design, reaching the market even before Chrome). Internet Explorer 9 and below are, for the most part, 32-bit browsers to ensure plugin compatibility, but Internet Explorer 10 can operate as a fully 64-bit browser by enabling Enhanced Protected Mode. 64-bit Internet Explorer also enables HE-ASLR.
Molehills, not mountains
And what of Mozilla's reasons for ditching 64-bit Windows builds? That the 64-bit version isn't a priority is apparent from the lack of supported build, but using that as an argument to discontinue creating 64-bit builds feels almost circular. The appropriate response would be to make it a priority, not ignore it entirely. Many other developers manage to properly distinguish between 32- and 64-bit crash reports and bugs, so it hardly seems credible for Mozilla to imply that it's somehow beyond its abilities.
JavaScript performance is important, and Internet Explorer 9 had a similar dichotomy between 32- and 64-bit performance. The JavaScript compilers used in modern scripting engines produce executable code from the JavaScript, and this executable code has to change depending on the bitness of the browser. Microsoft did the necessary work for 32-bit Internet Explorer, but not the 64-bit version, so that version omitted the compiler. In Internet Explorer 10, both 32- and 64-bit versions have the compiler and boast excellent JavaScript performance. There's no fundamental issue preventing Mozilla from doing so; it's just that the organization is allocating resources elsewhere.
Plugin availability is another issue, but it's an issue that leans even more heavily in favor of switching to 64 bits. The Java and Flash plugins, in particular, have suffered numerous security flaws in the past, and been significant infection vectors in their own right. Just like the browsers that host them, they're some of the pieces of code that most need the extra protection that 64-bit software has available. The latest versions of Flash, Java, and Silverlight all support 64-bit browsers.
And if those three aren't sufficient (and for many users, they will be) the solution chosen by Opera for its plugins is appealing. Though Opera, like Firefox, uses a single process for all tabs (rather than a tab per process), it also, like Firefox, runs plugins in separate external processes. Opera's trick is that the bitness of those processes doesn't have to match the bitness of the main Opera process; 64-bit Opera can spawn plugins in a 32-bit process. This isn't perfect, as it means that those 32-bit plugins don't get the security benefits of being 64-bit. But it allows a transition, and it means that the browser itself, and the plugins that are 64-bit ready, can take advantage of the greater security on offer in the meantime.
Mozilla maintains, and is going to continue to maintain, 64-bit builds for Mac OS X and Linux. Windows, however, is where the majority of Firefox's users actually are. As of October 2011, Firefox users running 64-bit Windows 7 outnumbered all Firefox users of Mac OS X and Linux combined, by a factor of about two to one. 64-bit users of Firefox's Nightly build currently outnumber 32-bit Nightly users. The 64-bit Windows target is substantial. Far from downplaying the significance of 64-bit and pushing the delivery of a 64-bit Windows Firefox into 2014 or beyond, Mozilla should be prioritizing the 64-bit browser, and striving to match Microsoft and Opera's progress. Firefox still has a lot of users; they deserve the security and stability that 64-bit browsers can provide.
Source
The stable, supported, mainstream version of Firefox on Windows is a 32-bit application. Even if you use 64-bit Windows, if you use Firefox, you're using a 32-bit browser. The exception is if you're using the Nightly build of Firefox. This represents the latest, cutting-edge version of the browser, and it's available in two versions: a 32-bit one, and a 64-bit one.
However, this won't last much longer. Mozilla announced last week it was no longer going to produce 64-bit Nightly builds of Firefox for Windows; nor will it run automated tests of 64-bit Firefox. The browser's future on Windows is resolutely 32-bit. Linux and Mac OS X, in contrast, both have official 64-bit versions.
Several reasons were given for this discontinuation: many plugins have no 64-bit version, Mozilla's bug reporting and tracking infrastructure provides no clear distinction between 32-bit and 64-bit problems, bugs go unfixed because the 64-bit Windows version is not deemed a priority, and JavaScript performance in the 64-bit builds is substantially slower than in the 32-bit version. Further, Mozilla developers say they won't fix any bugs that only manifest in 64-bit versions. Firefox developers say a fully supported 64-bit version of Firefox won't be released in the first half of 2013 and it probably won't make the second half either.
This is an unfortunate decision by Mozilla. 64-bit support is not important to all applications, but when it comes to Web browsers, it has a valuable role to play. At its core, the difference between 32- and 64-bit comes down to memory. Each 32-bit process gets 232 bytes (that is, 4GB, of memory to use). Each 64-bit process gets 264 bytes, 18EB, four billion times more memory, to play with. Of that 4GB that 32-bit processes can use, there's a further limitation: 32-bit Windows reserves 2GB or 1GB for itself, giving each 32-bit application only 2 or 3GB to use. 2GB is the default; to get 3GB, the application needs to opt in, and Windows needs to be booted in a special mode. On 64-bit Windows, 32-bit applications that opt in to 3GB support actually get almost the entire 4GB to themselves.
64-bit security
Why does memory matter so much for browsers? There are two reasons. One is common to all browsers; the other is more specific to Firefox. The first reason, the universal reason, is a little thing called security. Security flaws in browsers are an unfortunate fact, so operating system and browser developers both implement various features to try to reduce the impact of these security flaws. For example, one could run the browser in a low privilege sandbox so that malicious exploits cannot easily write to the user's hard disk.
One of these protective measures is called Address Space Layout Randomization, ASLR, and it works by moving DLLs and application memory into unpredictable locations within the 4GB that each 32-bit application has available to it. This makes exploitation harder, but on 32-bit systems the protection is limited. With only 4GB of space, there aren't that many random locations to choose. DLLs, for example, still need to be packed relatively close together, to ensure that there are large tracts of free space open for applications to store their own data in.
This lack of randomness is compounded by the fact that these days, 4GB just isn't that much memory. Filling all the memory with data that the attacker controls is now feasible. In a process known as heap spraying, attackers fill the victim application's memory with large blocks of code that do nothing, followed by their exploit code. This gives attackers much greater flexibility: instead of having to work out the exact memory location of their exploit, they just have to be somewhere close. As long as they find a location in the "do nothing" block, their exploit will run correctly.
In the world of 64-bit, this all changes substantially. With 18 exabytes (theoretically; real processors impose tighter constraints) of memory, there's plenty of room to scatter DLLs liberally making them needles in an unimaginably large haystack. A new Windows 8 feature called "High Entropy ASLR" does precisely this. The vast amount of memory also prevents any realistic attempt at heap spraying—the amount of memory is too large, and the amount that an attacker can fill up is too small.
For many applications, the stronger security provided by HE-ASLR and 64-bit computing probably isn't hugely valuable. As a practical matter, most applications have little meaningful exposure to the kind of attack that ASLR and HE-ASLR are meant to hinder. But Web browsers are a huge exception to this: they're huge vectors for malware, because they're routinely used to connect to networked resources that are beyond the control of any end-user.
Browsers need all the security mechanisms that developers can throw at them, and by sticking with 32-bit code, Firefox is unable to take advantage of some of the security features that Windows 8 has on offer.
64-bit stability
About time we mentioned there were two main issues with 32-bit on Firefox. That second problem is specific to this OS: Firefox is getting too big for a 32-bit memory space. Firefox does opt in to using 3GB of memory if it can, and 4GB when run on 64-bit systems, but this isn't enough. Except for plugins, everything Firefox does has to run within a single process: every tab you have open, every Firefox window you have open, every image, every script, every download, they're all sharing 4GB of memory. With lots of tabs—or complex pages and scripts, or even bugs within Firefox itself that cause memory to be allocated but then never freed when it's no longer needed—that 4GB can run out. As you approach the limit, Firefox gets slower and slower, as it has to work harder to make more memory available. Eventually it runs out, and typically, it crashes. (This limitation was one of the big reasons I switched back to Chrome, in spite of my preference for Firefox's appearance and interface.)
64-bit Firefox, by virtue of having so much more memory available, would essentially never run out of memory.
Mozilla is working to alleviate the issue somewhat. Since version 13, Firefox already has on-demand loading of tabs: restart the browser and any tabs that you don't look at don't actually get loaded, saving memory. Mozilla developers are also planning a feature that would unload tabs you aren't currently using, again making more memory available. But these are both stopgap measures. These are of little assistance when tabs legitimately require lots of memory, or when multiple tabs are in regular active usage.
A robust solution to this problem does not strictly require the use of 64-bit. Chrome on Windows is also a 32-bit browser (though there is some effort underway to produce a 64-bit version), but because Chrome strives to have one process per tab, the resource constraints are much less acute. Instead of having to fit everything within 4GB, Chrome only needs to fit a single Web page within 4GB. Different tabs each get their own 4GB to operate in. This doesn't offer Chrome the security benefits of using 64 bits, but at least prevents it from running out of memory.
Mozilla once embarked on a project to bring this kind of capability to Firefox. It was called Electrolysis, but the project has been all but cancelled. It's unlikely to offer salvation any time soon.
Opera, which shares Firefox's mostly-single-process design, has a fully-supported 64-bit version, so like Chrome, it too avoids the resource constraints. Unfortunately, Opera does not support HE-ASLR and so does not take advantage of all that 64-bit has to offer.
Internet Explorer has a multi-process design (indeed, it was the first mainstream browser to use such a design, reaching the market even before Chrome). Internet Explorer 9 and below are, for the most part, 32-bit browsers to ensure plugin compatibility, but Internet Explorer 10 can operate as a fully 64-bit browser by enabling Enhanced Protected Mode. 64-bit Internet Explorer also enables HE-ASLR.
Molehills, not mountains
And what of Mozilla's reasons for ditching 64-bit Windows builds? That the 64-bit version isn't a priority is apparent from the lack of supported build, but using that as an argument to discontinue creating 64-bit builds feels almost circular. The appropriate response would be to make it a priority, not ignore it entirely. Many other developers manage to properly distinguish between 32- and 64-bit crash reports and bugs, so it hardly seems credible for Mozilla to imply that it's somehow beyond its abilities.
JavaScript performance is important, and Internet Explorer 9 had a similar dichotomy between 32- and 64-bit performance. The JavaScript compilers used in modern scripting engines produce executable code from the JavaScript, and this executable code has to change depending on the bitness of the browser. Microsoft did the necessary work for 32-bit Internet Explorer, but not the 64-bit version, so that version omitted the compiler. In Internet Explorer 10, both 32- and 64-bit versions have the compiler and boast excellent JavaScript performance. There's no fundamental issue preventing Mozilla from doing so; it's just that the organization is allocating resources elsewhere.
Plugin availability is another issue, but it's an issue that leans even more heavily in favor of switching to 64 bits. The Java and Flash plugins, in particular, have suffered numerous security flaws in the past, and been significant infection vectors in their own right. Just like the browsers that host them, they're some of the pieces of code that most need the extra protection that 64-bit software has available. The latest versions of Flash, Java, and Silverlight all support 64-bit browsers.
And if those three aren't sufficient (and for many users, they will be) the solution chosen by Opera for its plugins is appealing. Though Opera, like Firefox, uses a single process for all tabs (rather than a tab per process), it also, like Firefox, runs plugins in separate external processes. Opera's trick is that the bitness of those processes doesn't have to match the bitness of the main Opera process; 64-bit Opera can spawn plugins in a 32-bit process. This isn't perfect, as it means that those 32-bit plugins don't get the security benefits of being 64-bit. But it allows a transition, and it means that the browser itself, and the plugins that are 64-bit ready, can take advantage of the greater security on offer in the meantime.
Mozilla maintains, and is going to continue to maintain, 64-bit builds for Mac OS X and Linux. Windows, however, is where the majority of Firefox's users actually are. As of October 2011, Firefox users running 64-bit Windows 7 outnumbered all Firefox users of Mac OS X and Linux combined, by a factor of about two to one. 64-bit users of Firefox's Nightly build currently outnumber 32-bit Nightly users. The 64-bit Windows target is substantial. Far from downplaying the significance of 64-bit and pushing the delivery of a 64-bit Windows Firefox into 2014 or beyond, Mozilla should be prioritizing the 64-bit browser, and striving to match Microsoft and Opera's progress. Firefox still has a lot of users; they deserve the security and stability that 64-bit browsers can provide.
Source