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.

245 Reader Comments

As someone who is using the 64bit nightly build for Windows...this sucks. Sure nightly's had some serious showstopper bugs(but what's to be expected from a nightly?) but overall I like it much better than Chrome and it handles my 20+ tabs like a champ. Back to 32bit Aurora then.

Can't you just use PAE on modern Windows to get around the memory limit? And in the short term at least, most users probably only have 4GB, and at most 8GB, of RAM, so your stack spraying issue isn't going to be mitigated by a 64-bit build. There is really very little additional inherent security in building an application for x86_64 (since HE-ASLR requires large quantities of memory to be particularly effective). There really isn't a pressing need for 64-bit Firefox, but I'm sure they'll move there eventually.

Flash and Java plugins just need to die, that'd solve most of the plugin problem.

Well, I guess they should prioritize the ARM version on Windows as well, then. I wonder how WebGL's working on Windows 8 tablets, for instance.

Of course, the majority of Windows users aren't using Windows 8, but have 64-bit capable processors. It does seem like an odd decision, although it seems Mozilla has favored OS X behind the scenes far more than Windows or Linux. While it's probably not entirely true, all of their screenshots seem to be from within OS X.

How is 32-bit/64-bit/4GB memory limitations handled in Safari? I thought separate process per tab was implemented in Safari 5.1 in 2011 as part of WebKit2 even for the 32-bit Windows version. 64-bit Safari in OS X can use 32-bit plugins in a separate process starting with Safari 4 as part of Snow Leopard since 2009 I believe.

As much as people love to decry the death of flash, it's a pain to browse the web without it still. You can't drop support for flash/silverlight/java and expect to remain a popular browser. I think Mozilla should focus on the project to split into multiple processes, this solves the memory issue, and a new project to sandbox like chrome.

As much as people love to decry the death of flash, it's a pain to browse the web without it still. You can't drop support for flash/silverlight/java and expect to remain a popular browser. I think Mozilla should focus on the project to split into multiple processes, this solves the memory issue, and a new project to sandbox like chrome.

Can't you just use PAE on modern Windows to get around the memory limit? And in the short term at least, most users probably only have 4GB, and at most 8GB, of RAM, so your stack spraying issue isn't going to be mitigated by a 64-bit build. There is really very little additional inherent security in building an application for x86_64 (since HE-ASLR requires large quantities of memory to be particularly effective). There really isn't a pressing need for 64-bit Firefox, but I'm sure they'll move there eventually.

Flash and Java plugins just need to die, that'd solve most of the plugin problem.

Depending on how the memory manager works (come on Arsians, you know this... enlighten us), HE-ASLR may not need a real TB of memory to allocate a TB of memory space. The blocks actually allocated for use need addresses, but the unused blocks in between don't need to really exist. Heap spraying would cause the allocation of many, many blocks and probably lead to a crash.

This depends on the process and the OS both being aware of the HE-ASLR status. The application requests (for example) 4TB of address space and estimates 4GB of real space requirements. The OS hands back an address space of 4TB and reserves the right to issue out-of-memory errors starting around 4GB's worth of allocated blocks. This has overhead (something akin to a FAT for each process), but not nearly as much as wrangling 4TB of virtual memory.

And in the short term at least, most users probably only have 4GB, and at most 8GB, of RAM, so your stack spraying issue isn't going to be mitigated by a 64-bit build.

Sure it is. You can spray 4 or 8 GB out of an address space of 18 EB. The chance of spraying the right spot is slim.

Quote:

There is really very little additional inherent security in building an application for x86_64 (since HE-ASLR requires large quantities of memory to be particularly effective). There really isn't a pressing need for 64-bit Firefox, but I'm sure they'll move there eventually.

HE-ASLR doesn't require large quantities of memory; it just requires large virtual address spaces, which is what we have.

Huh, now looking to see whether Office is 64 bit yet, I see on Microsoft's own technet site for 64-bit Office 2013:

"Processors that are 64-bit are becoming the standard for systems that range from servers to desktop computers. " Are becoming? Really? Like... 6 years ago, not in 2012 heading into 2013.

and then:

"If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on earlier versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2013 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems."

Ouch. So Firefox, you're apparently not alone in not being able to effectively move to 64 bit - Microsoft can't pull it off well for their bread-and-butter app. Pathetic, but so it goes.

Can't you just use PAE on modern Windows to get around the memory limit? And in the short term at least, most users probably only have 4GB, and at most 8GB, of RAM, so your stack spraying issue isn't going to be mitigated by a 64-bit build. There is really very little additional inherent security in building an application for x86_64 (since HE-ASLR requires large quantities of memory to be particularly effective). There really isn't a pressing need for 64-bit Firefox, but I'm sure they'll move there eventually.

A couple comments:

PAE only removes the 4GB limit for the system as a whole. Any single process can still only address 4GB. This is achieved through being able to say "these pages in 32-bit address space should be translated to this chunk of 36-bit address space". So PAE doesn't do a lick of good if Firefox's single process is actually pushing enough memory to run out. And that is pretty easy since the kernel is usually mapped into ~1GB of your address space, leaving 3GB for your app to use.

Also, 64-bit addressing can be used even if you don't have enough RAM. Because of how modern memory works, a 64-bit address isn't a literal RAM address. It's a virtual address that the CPU translates into a physical one. The kernel adjusts a translation map in the CPU when there is a context switch between processes. You can randomly place your app's memory all over the 64-bit address space and then use this translation map to point these random addresses to more logical ones. Anything not mapped will throw errors (page faults). So yeah, having a 64-bit process with HE-ASLR is beneficial, since you don't actually need the physical RAM to take advantage of the very large virtual address space.

Thats a bummer... I really hope both Chrome and FF actually release 64-bit versions sooner than later though... With chrome its a bit more sticky - without 64-bit support you can not run ANY native chrome apps (nacl) in 64bit windows...

Huh, now looking to see whether Office is 64 bit yet, I see on Microsoft's own technet site for 64-bit Office 2013:

"Processors that are 64-bit are becoming the standard for systems that range from servers to desktop computers. " Are becoming? Really? Like... 6 years ago, not in 2012 heading into 2013.

and then:

"If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on earlier versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2013 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems."

Ouch. So Firefox, you're apparently not alone in not being able to effectively move to 64 bit - Microsoft can't pull it off well for their bread-and-butter app. Pathetic, but so it goes.

Office 64bit works fine on its own without plugins and whatnot (I don't use any, so I don't care) but many enterprises do, and up until recently, have been on Windows XP which is a 32bit-only OS (XP 64bit is server 2003 with XP branding and reportedly a minefield of incompatibility issues with drivers; Disclaimer: I never used it) Now that Win7 64Bit is being the standard in the enterprise space, 64bit adoption is finally picking up as machines with 8GiB of RAM become the new baseline.

I personally use a machine with 32GiB of RAM and 64bit everything as far as possible.

Mozillans have said that they do like to release a high-quality Win64 build eventually, but they are, at the end of the day, a not-for-profit foundation with limited resources. The Windows team has actively prioritised the "Metro UI" build (rightfuly IMO), and between that and the Firefox OS project, they don't have the resources to dedicate to a 64-bit Windows build. As they don't have the resources to triage bugs and fix issues with the nightly, they are (for now) discontinueing it.

In an ideal world, of course Mozilla would have a 64-bit build for Windows, but when resources are tight, one has to make sacrifices.

On another note, why is it that both Chrome and Firefox have 64-bit builds for Linux and OS X but not for Windows? Is building 64-bit binaries somehow more difficult on Win64 (are the toolchain and the build environments that different?)

I was using Nightly just because it was x64 build. What bothers me is, they plan to revert users like me to x86 without even a single warning/notice.

Eventually, I removed everything Fx-related and went to Chrome, likewise. My first days since Mozilla announced this and I'm pretty fine. Even in the add-ons part, I find the situation more vivid in Google's camp.

Also, I wouldn't say "suspend" is the best word to describe Mozilla's will. The project has been cancelled, not that they cared as long as it was "alive".

Huh, now looking to see whether Office is 64 bit yet, I see on Microsoft's own technet site for 64-bit Office 2013:

"Processors that are 64-bit are becoming the standard for systems that range from servers to desktop computers. " Are becoming? Really? Like... 6 years ago, not in 2012 heading into 2013.

Definitely. I checked Newegg. The only PCs they sell that don't include 64 bit Windows are old refurbished units. And since no one sells PCs with less than 6GByte memory now days, I doubt that there is anyone selling machines with 32 bit Windows installed (other than tiny niche markets).

Usually, in PC history, hardware was behind software. Windows 1 through Vista, and much of the applications, always ran slow because the hardware hadn't caught up to the latest software features.

Now, it appears, it has reversed. Microsoft and Firefox, and even Google, are putting out software for four year old hardware--hardware you can't even buy anymore. Yes, it runs, in a special 32 bit mode. I can run MSDOS Pong on my machine too if I run a DOS simulator, but it really isn't exactly taking advantage of the hardware.

If anyone is familiar with the current dictatorial way Mozilla organizes itself, you would know that hard headed nazis (not in the literal sense) like Asa is doing to Mozilla what Sinofsky did to Microsoft. Their campus are filled with Macs and Linuxes that make you think is Mozilla developing for anything else but OSX?

As much as their javascript engine had improved to be formidable to V8 and Charkra, they completely forgot about their Gecko layout engine. It doesn't matter how fast the future IonMonkey can be when Gecko can't keep up to render the stuff from it. Their UI performance craws to a halt with anything more than 5 tabs open. All the belts and whistles animation like tabs reorder and such drop frame considerably.

And now facebook integration and firefox OS? You know as much as I'm not a fan of Chrome, I do hope they take over and leave Mozilla dried.

How is 32-bit/64-bit/4GB memory limitations handled in Safari? I thought separate process per tab was implemented in Safari 5.1 in 2011 as part of WebKit2 even for the 32-bit Windows version. 64-bit Safari in OS X can use 32-bit plugins in a separate process starting with Safari 4 as part of Snow Leopard since 2009 I believe.

It's certainly something like that. IIRC, Snow Leopard brought the full 64-bit APIs through to Cocoa (GUI apps), where previously it was recommended that you do 64-bit backend processes that communicate with a 32-bit GUI shell, and I think you're totally right that Safari handles both 64 and 32-bit plugins.

Another amazing thing to see on Windows is the split between installing 32 or 64 bit versions and therefore determining which versions of apps you can run.* Microsoft was seemingly so busy toking from their own "we're innovators" pipe that they didn't notice when the rest of the industry passed them by.

Sinofsky is gone, Ozzie took off... Well, at least they still have Ballmer.

*And in order to not live in that world, Apple cuts off support for old hardware which ticks off other people. Probably the people who would rather run 32-bit apps forever, but so it goes. Everyone can't be happy, but if you're on a platform where some of the largest apps can't move to 64-bit, I'd worry a bit.

No doubt 64-bit Firefox should be prioritized. The question is, given Mozilla's limited resources, *how* it should be prioritized. Is it more or less important than other crucial projects being worked on? For example, more or less important than off-main-thread compositing? More or less important than new DOM bindings that make common operations faster? More or less important than new security and stability improvements? More or less important than implementing new HTML or CSS standards? (Obviously not in all cases is there dev overlap, but in many there is.)

Everyone agrees 64-bit Firefox is important, but the question isn't yes or no, it's how much. I do agree it should be "highly prioritized", but then so should other things being worked on. Mozilla doesn't have Google, Microsoft or Apple's resources.

Huh, now looking to see whether Office is 64 bit yet, I see on Microsoft's own technet site for 64-bit Office 2013:

"Processors that are 64-bit are becoming the standard for systems that range from servers to desktop computers. " Are becoming? Really? Like... 6 years ago, not in 2012 heading into 2013.

and then:

"If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on earlier versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2013 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems."

Ouch. So Firefox, you're apparently not alone in not being able to effectively move to 64 bit - Microsoft can't pull it off well for their bread-and-butter app. Pathetic, but so it goes.

Office 64-bit itself is fine. The warning is if you rely on addons that might not work on 64-bit. Surprisingly, the addons we use at work are Office 64-bit ready.

And unlike Mozilla, Microsoft actually has now released two major versions of Office with 64-bit versions.

Mozilla has a poor excuse. The most popular addons, Flash, Java and Silverlight, are 64-bit ready. I have 15 extensions that didn't go boom in switching to 64-bit Nightly.

I really don't understand the outrage. Linux has had 64-bit builds of Firefox for years... and we also had Flash crashing every other page load for years. Sorry, person who can't do their job without 100 tabs open (who inexplicably shows up in every thread about Firefox), but 64-bit support seems like more of a "nice to have", and I can completely understand why they think normal people would care more about things like matching the native interface.

On having only a 32-bit only version for Windows and a 64-bit version for OS X and Linux, Chrome is the exact same way. I know because I have used Chrome on all three OSes (dual-boot Windows/Linux at home and OS X at work). The reason I believe is that 1) OS X and Linux are Unix-like and you don't have to do the weird stuff like what you have to do with C++ on Windows and 2) Google doesn't like Windows.

EDIT: Having to rewrite the JavaScript-to-native compiler is not an easy task due to the fact that one has to generate executable code in C using opcodes specific to that processor architecture (x86, x86-64, ARM, etc.) and is not very fun. I tried generating my own machine code in C once and I got it to add a few numbers together to get 16. It's not a task for the faint of heart as you have to use special memory protections and the craziness described above.

Huh, now looking to see whether Office is 64 bit yet, I see on Microsoft's own technet site for 64-bit Office 2013:

"Processors that are 64-bit are becoming the standard for systems that range from servers to desktop computers. " Are becoming? Really? Like... 6 years ago, not in 2012 heading into 2013.

Definitely. I checked Newegg. The only PCs they sell that don't include 64 bit Windows are old refurbished units. And since no one sells PCs with less than 6GByte memory now days, I doubt that there is anyone selling machines with 32 bit Windows installed (other than tiny niche markets).

Usually, in PC history, hardware was behind software. Windows 1 through Vista, and much of the applications, always ran slow because the hardware hadn't caught up to the latest software features.

Now, it appears, it has reversed. Microsoft and Firefox, and even Google, are putting out software for four year old hardware--hardware you can't even buy anymore. Yes, it runs, in a special 32 bit mode. I can run MSDOS Pong on my machine too if I run a DOS simulator, but it really isn't exactly taking advantage of the hardware.

To be clear, I was amazed to see Microsoft making the claim that 64-bit machines are just now "becoming the standard" - and I totally agree that you'd be hard pressed to find 32-bit hardware at this point.

The fact that they can't get Office to work well enough in 64-bit mode to recommend that as the standard install is really telling and helps to justify the Firefox team's decision when MS can't seem to get to 64-bits cleanly yet. 64-bit machines have been common for *at least* 6 years (I'm not saying Windows 64 sales, just that hardware got out ahead of them), and it just astounds me that Office 2013 seemingly isn't ready for the new world yet. Ouch.

No doubt 64-bit Firefox should be prioritized. The question is, given Mozilla's limited resources, *how* it should be prioritized. Is it more or less important than other crucial projects being worked on? For example, more or less important than off-main-thread compositing? More or less important than new DOM bindings that make common operations faster? More or less important than new security and stability improvements? More or less important than implementing new HTML or CSS standards? (Obviously not in all cases is there dev overlap, but in many there is.)

More important than Facebook integration and 3D visualization of the DOM tree, at the very least.

And, yes, more important than contaminating the Web with the latest prefixed non-standards.

Quote:

Everyone agrees 64-bit Firefox is important, but the question isn't yes or no, it's how much. I do agree it should be "highly prioritized", but then so should other things being worked on. Mozilla doesn't have Google, Microsoft or Apple's resources.

Then maybe Mozilla needs to run its business better. At the moment, Mozilla brings in less money even than Opera. That seems pretty poor.

To be clear, I was amazed to see Microsoft making the claim that 64-bit machines are just now "becoming the standard" - and I totally agree that you'd be hard pressed to find 32-bit hardware at this point.

Actually, it's utterly trivial to do so, since all current ARM systems are 32-bit, as are many Atom systems.

Quote:

The fact that they can't get Office to work well enough in 64-bit mode to recommend that as the standard install is really telling and helps to justify the Firefox team's decision when MS can't seem to get to 64-bits cleanly yet.

No it doesn't. Office has to work with 20 years of custom code that companies have developed for internal, line-of-business applications; code that is almost invariably 32-bit. The extension API is also extremely big, and extremely complex, which makes hosting add-ons out-of-process complex.

Firefox has to work with Flash, Java, and Silverlight (all of which are available already as 64-bit plugins), and interacts using the narrow, simple NPAPI API, which makes out-of-process simple enough that four different browsers (Chrome, Opera, Safari, and, yes, Firefox) have all done it.

Quote:

64-bit machines have been common for *at least* 6 years (I'm not saying Windows 64 sales, just that hardware got out ahead of them), and it just astounds me that Office 2013 seemingly isn't ready for the new world yet. Ouch.

Can't you just use PAE on modern Windows to get around the memory limit? And in the short term at least, most users probably only have 4GB, and at most 8GB, of RAM, so your stack spraying issue isn't going to be mitigated by a 64-bit build. There is really very little additional inherent security in building an application for x86_64 (since HE-ASLR requires large quantities of memory to be particularly effective). There really isn't a pressing need for 64-bit Firefox, but I'm sure they'll move there eventually.

Flash and Java plugins just need to die, that'd solve most of the plugin problem.

HE-ASLR can be and is useful with any amount of ram. No program ever gets the actual physical address of where it is being stored in memory. Each gets it's own virtual address space that the memory manager then maps to actual locations that could be someplace in ram or even on the swap. Also the location in ram can change while the program is running but it would never know because the memory manager hides this. This means that the program and HE-ASLR can randomize across the entire addressable memory space for that program even if you only have a couple gbs of memory installed.

A better job getting plugins to transition to 64-bit? Do you realize the audience who wouldn't have 64-bit ready plugins is the same audience that still uses XP and IE6 because of shitty internal LOB applications or some such? I know it's cool to hate on Microsoft, but pick your battles. This isn't one of them. Office 64-bit itself is fine. Putting a wrapper and saying "it might work" is an absolute no-go in the enterprise.

For the last few years, Firefox has been the least secure of the three major browsers. It was the last major browser to support process isolation, it was the last major browser to sandbox its plugins, and, of course, it has always had pitiful 64 bit/ASLR support.

This merely reaffirms Mozilla's commitment to ignore security. At this point, Mozilla is realising that its the extensions community (or the toolbar bastards, depending on how you look at it) which is keeping it afloat and so has to pander to this community, or be sunk by the superiority of Chrome and IE10.

Office 64-bit itself is fine. The warning is if you rely on addons that might not work on 64-bit. Surprisingly, the addons we use at work are Office 64-bit ready.

And unlike Mozilla, Microsoft actually has now released two major versions of Office with 64-bit versions.

Mozilla has a poor excuse. The most popular addons, Flash, Java and Silverlight, are 64-bit ready. I have 15 extensions that didn't go boom in switching to 64-bit Nightly.

Microsoft should have done a better job either getting plugins to transition to 64-bits and/or put a compatibility wrapper in themselves. It's messed up if they have to give advice to users to basically stick with the 32-bit version of Office 2013. That it _may_ work fine is a given (and really I would think in many/most cases, even???), but that they lack enough confidence to move forward and recommend 64-bits is totally Ballmered.

The compatibility layer would be huge, and what's the upside? The only app that seriously benefits from 64-bit is Excel. For the rest, it's basically irrelevant.

For me, the bottom line is if you can't get your browser to run in less than 4 gigs of memory, you need to hang up your keyboard. Moores law is going in reverse now, we're going to tablets and smartphones and all manner of weaksauce computing devices. We need to get rid of all sorts of obsolete baggage, like Flash, Java, Quicktime and ... Firefox (Not on mobile? No longer relevant.)

It's not a matter of the _developers_ getting it to run in less than 4GB, it's users like my wife who opens tab after tab after tab after tab after... (If you see where I'm going with that ) where some sites are still using Flash, and suddenly your browser is certainly using over 4GB. (Or even worse, the 2GB that Windows typically made available - not sure if WOW64 or whatever MS calls it at least gives more like 4GB, seems like it should...)

Moore's Law is certainly not going in reverse even if it has run into issues ramping up pure clock speed on desktops - look at the progression of mobile CPUs and see how those track, don't compare to a desktop box. That current mobile devices are under 4GB of RAM is fine, but phones are already up to 1-2GB (from just 128MB with the iPhone launch), and given another couple of years will easily be carrying 4-8GB RAM assuming 64-bit ARM and low-power x86 uptake.

Looking at the 4KB first machine I coded on, I wouldn't call todays portable devices anything like "weaksauce". I'd have given [somebody else's] left nut for a machine as powerful as my phone even 15 years ago. (I think my first machine with 1GB was maybe 2001 or 2002?)