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.

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.

If you read the quote from Microsoft tbey DO recommend 64 bit Office EXCEPT when there are required addons created by/for early versions of Office using tools that generate code that does not interface properly with 64bit Office.

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.

Office x64 works just fine. Really.

There's two reasons why MS recommend the x86 version though - addons and macros. Addons have been discussed already, but there was simply no way around breaking *something* with x64 builds and macros.

VBA has no pointer type so everyone uses long for that when calling external (eg C/C++) code. Long is 32 bits in VBA (integer is 16, VBA predates win32!). You can't keep code that assumes long is big enough for a 64 bit pointer (eg some declare function calls) and code that assumes long is 32 bits (pretty much anything else - it's not just a change in integer overflow behaviour) working at the same time. Their solution was to essentially deprecate delare function and require it to be rewritten as declare ptrsafe function - the idea being that you check whether you're using long incorrectly (you probably are) at the same time.

For a small amount of code it's hardly a major change (and if you're not using declare statements/32 bit libraries everything is likely to just work with no changes), but VBA is used extensively and there's no real guarentee that there's anyone around that still knows what said code is doing (or given it's VBA whether anyone ever did in the first place). IE it could be a considerable amount of work to migrate your code.

Hence the recommendation has nothing to do with office itself, but rather an oversignt in the original 16 bit VBA language a long time ago that probably wasn't even a bad idea then.

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?)

It's not that it can't be built. It's that they won't have an official release of the build. So if you have any bugs, they will be dismissed if they are submitted.

To moan about how FireFox isn't 64-bit compatible, when the default browser is set to run in 32-bit mode, is just stupid.

In Windows 8, which ships with Internet Explorer 10, the default browser is Metro Internet Explorer, which is 64-bit by default. Desktop Internet Explorer 10 is 32-bit by default, but can have 64-bit enabled.

Quote:

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app. And you have to [as far as I can determine] have installed 64-bit Windows to begin with, which less than 1/2 of all users have done [at least as googling it can determine].

If the Steam hardware survey is anything to go by, 64-bit Windows 7 installations are more numerous than 32-bit; I expect the trend to be even more pronounced with Windows 8.

Quote:

Beyond Microsoft's crazy 64-bit support [separate 32 and 64 bit OS and application installs, where the end user needs to make sure they install the right version],

Fat binaries would be nice, but the mix of bitnesses is perfectly reasonable.

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app.

Not true. Chrome has passed IE as the most used browser on the web, and IE hasn't had a "vast majority" probably since 2009.

I'm curious if the default Metro version of IE in Windows 8 is 64-bit or 32-bit.

Either way, Mozilla has 50 projects going on at once, and a stable 64-bit build has been in the works since 2003, but it has never been made a priority. They juggle several eggs at once, but seem to fail to deliver on the most important ones these days. And their rich library of extensions doesn't mean much when their rapid releases frequently break extensions.

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.

There is no 64-bit version of Chrome for OS X. It's all still 32-bit. As far as I know, there's not even a beta of a 64-bit version of Chrome for OS X.

Also, as a side note. Mozilla is working on a new browser engine called Servo (https://github.com/mozilla/servo). It's built in their own language Rust. It should address a lot of issues that people have with existing engine. Hopefully something comes of it.

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app.

Not true. Chrome has passed IE as the most used browser on the web, and IE hasn't had a "vast majority" probably since 2009.

Chrome hasn't. Take a look at the stats from Net Marketshare and Akamai. IE still has a substantial lead.

Also, as a side note. Mozilla is working on a new browser engine called Servo (https://github.com/mozilla/servo). It's built in their own language Rust. It should address a lot of issues that people have with existing engine. Hopefully something comes of it.

I think Rust is an interesting looking language with a nice mix of features, but it's a total non-starter if they want Servo to become mainstream, in my view. Making potential contributors learn a new language, a language with considerably worse tooling than C++, is not even remotely palatable.

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app.

Not true. Chrome has passed IE as the most used browser on the web, and IE hasn't had a "vast majority" probably since 2009.

Chrome hasn't. Take a look at the stats from Net Marketshare and Akamai. IE still has a substantial lead.

They don't filter out false results from applications that register as an IE user-agent, such as AVG anti-virus. That is why StatCounter, W3Counter, WikiMedia and Clicky all report similar numbers (all with Chrome surpassing IE) and NetMarketshare alone reports IE having a major lead.

NetMarketshare also pulls their metrics from only 40,000 sites (mainly based in the US) while StatCounter for example pulls their metrics from over 3 million sites. NetMarketshare has come under fire for their OS metrics being way off in the past as well.

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app.

Not true. Chrome has passed IE as the most used browser on the web, and IE hasn't had a "vast majority" probably since 2009.

Chrome hasn't. Take a look at the stats from Net Marketshare and Akamai. IE still has a substantial lead.

They don't filter out false results from applications that register as an IE user-agent, such as AVG anti-virus. That is why StatCounter, W3Counter, WikiMedia and Clicky all report similar numbers (all with Chrome surpassing IE) and NetMarketshare alone reports IE having a major lead.

NetMarketshare also pulls their metrics from only 40,000 sites (mainly based in the US) while StatCounter for example pulls their metrics from over 3 million sites. NetMarketshare has come under fire for their OS metrics being way off in the past as well.

Akamai agrees pretty well with Net Marketshare, so Net Marketshare isn't alone at all. Net Marketshare is also the source that Mozilla reports. It's also roughly consistent with the number of Chrome users that Google claims to have.

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app.

Not true. Chrome has passed IE as the most used browser on the web, and IE hasn't had a "vast majority" probably since 2009.

Chrome hasn't. Take a look at the stats from Net Marketshare and Akamai. IE still has a substantial lead.

They don't filter out false results from applications that register as an IE user-agent, such as AVG anti-virus. That is why StatCounter, W3Counter, WikiMedia and Clicky all report similar numbers (all with Chrome surpassing IE) and NetMarketshare alone reports IE having a major lead.

NetMarketshare also pulls their metrics from only 40,000 sites (mainly based in the US) while StatCounter for example pulls their metrics from over 3 million sites. NetMarketshare has come under fire for their OS metrics being way off in the past as well.

Statistically the sample size difference is completely irrelevant. Yes 3 million is more than 40k, but no it doesn't matter - really, it doesn't. What matters far more is sampling bias, and that's a big problem for both.

As for why they're so different, IIRC it has a lot to do with how they weight China.

A single person is able to recompile Firefox in a 64bit compiler easily keeping up with each release. Waterfox is great example that shows Mozilla needs to rethink 64bit FF, and in the mean time more people should try it. It can run alongside the existing install of Firefox, automatically shares the default profile, so your settings and everything are the same in both browsers. No downside.

The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app.

Not true. Chrome has passed IE as the most used browser on the web, and IE hasn't had a "vast majority" probably since 2009.

Chrome hasn't. Take a look at the stats from Net Marketshare and Akamai. IE still has a substantial lead.

They don't filter out false results from applications that register as an IE user-agent, such as AVG anti-virus. That is why StatCounter, W3Counter, WikiMedia and Clicky all report similar numbers (all with Chrome surpassing IE) and NetMarketshare alone reports IE having a major lead.

NetMarketshare also pulls their metrics from only 40,000 sites (mainly based in the US) while StatCounter for example pulls their metrics from over 3 million sites. NetMarketshare has come under fire for their OS metrics being way off in the past as well.

Akamai agrees pretty well with Net Marketshare, so Net Marketshare isn't alone at all. Net Marketshare is also the source that Mozilla reports. It's also roughly consistent with the number of Chrome users that Google claims to have.

Net Marketshare also repeatedly cited OS X market share double of what it really was (which is relatively easy to track by Mac hardware sales) until they got called out on it.

As Dayvid noted, China makes a huge difference. As Net Marketshare only gathers metrics from English-speaking websites primarily based in the US, it isn't remotely a fair indicator of global market share. Just because Mozilla (or Ars Technica) cites them doesn't magically make their methodology sane or logical for supposed global metrics when you ignore most of the globe.

The vast majority of people have no idea what the differences between 64bit and 32bit are, it makes virtually zero difference in their day to day browsing experience. People just want something that works, no fuss, no mess, I don't think a 32-bit only policy violates that.

64-bit ASLR isn't a magic bullet. Yes it makes it harder for malicious compiled JS to call library functions but that's about it, there are always way easier programming errors to exploit despite the existence of ASLR. At least Firefox is open source and has more eyes looking at it, can't say the same thing for IE. Despite that, 32bjt ASLR is still pretty good, you have ~10 known DLLs loaded in a process and ~3bn places to put them, odds aren't great.

What's with all the hate for Mozilla for making a change that has literally no effect on people's browsing experience but will allow them to accomplish their goals of an open web much more efficiently? That's not cool. That's really not cool. You people have no idea what it's like to produce real software that has to run on millions of machines. What a world where people would betray the single organization that dragged us out of the dark ages of web browsing for such a stupid reason. Mozilla is fighting for you...

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.

Other's have explained the difference between virtual and physical address space so I will not go over that again here. But there is a far bigger security benefit for 64bit (on windows) : Structured Exception Handling (SEH) which is stack based. This is a major vulnerability since it can be overwritten by a stack based buffer overrun vulnerability. This is far more problematic than overwriting the return address as /GS protection causes the compiler to add code to check a stack canary before the RET in most "risky" functions but exceptions can occur at any point (null deref/div by zero) and jump straight to the handler (not via the canary code) so are not protected by /GS. Under 64bit the handlers are table based (marked read only in a special section of the exe) so not usable by buffer overruns completely plugging this massive vector. This was only possible since 64bit code needs a complete recompile so MS could break from the legacy mechanism entirely.

Note:Under 32bit the current exception handler is actually accessed via a pointer in the thread environment block (TEB) which is in turn pointed to via the FS segment selector on the CPU. When a function sets up a new handler it has to push the old value on the stack, it is this back link pointer (supports chained exceptions) that is vulnerable.SafeSEH can be used to protect 32bit processes but only if the exe and EVERY DLL in the process enable it. SEHOP also protects you by checking the entire chain is valid before calling it but not all applications enable it, it needs ALSR to not be trivial to bypass and even then it can be defeated by information disclosure vulnerabilities.

Yes it makes it harder for malicious compiled JS to call library functions but that's about it, there are always way easier programming errors to exploit despite the existence of ASLR.

No, that is increasingly not the case.

Quote:

At least Firefox is open source and has more eyes looking at it, can't say the same thing for IE.

That has no implications for its security.

Quote:

Despite that, 32bjt ASLR is still pretty good, you have ~10 known DLLs loaded in a process and ~3bn places to put them, odds aren't great.

It isn't anything like that good. There are a few hundred places it can put things, not billions.

Quote:

What's with all the hate for Mozilla for making a change that has literally no effect on people's browsing experience but will allow them to accomplish their goals of an open web much more efficiently? That's not cool. That's really not cool. You people have no idea what it's like to produce real software that has to run on millions of machines. What a world where people would betray the single organization that dragged us out of the dark ages of web browsing for such a stupid reason. Mozilla is fighting for you...

No, Mozilla isn't fighting for me. Mozilla is producing a browser that I had to stop using because it consistently runs out of memory, and which is less secure than the competition. That's not fighting for anyone.

Yes it makes it harder for malicious compiled JS to call library functions but that's about it, there are always way easier programming errors to exploit despite the existence of ASLR.

No, that is increasingly not the case.

Quote:

At least Firefox is open source and has more eyes looking at it, can't say the same thing for IE.

That has no implications for its security.

Quote:

Despite that, 32bjt ASLR is still pretty good, you have ~10 known DLLs loaded in a process and ~3bn places to put them, odds aren't great.

It isn't anything like that good. There are a few hundred places it can put things, not billions.

Quote:

What's with all the hate for Mozilla for making a change that has literally no effect on people's browsing experience but will allow them to accomplish their goals of an open web much more efficiently? That's not cool. That's really not cool. You people have no idea what it's like to produce real software that has to run on millions of machines. What a world where people would betray the single organization that dragged us out of the dark ages of web browsing for such a stupid reason. Mozilla is fighting for you...

No, Mozilla isn't fighting for me. Mozilla is producing a browser that I had to stop using because it consistently runs out of memory, and which is less secure than the competition. That's not fighting for anyone.

Waterfox needs to be getting some more traction, especially with Mozilla shutting down 64-bit nightlies. So far, so good; aside from making sure that 64-bit Java, Flash, and Silverlight were installed, I can't really tell the difference, because all of my extensions are there from my Firefox profile and just work.

Too many people misunderstand the significant difference between "memory" and "address space". Peter confusingly conflates the two in this article, starting in the fourth paragraph. I wish he'd taken greater pains to distinguish the two and explain why it matters.

We really do need a 64-bit Firefox. I've experimented with Waterfox, but while it's a rather ingenious variant (it re-uses an existing Firefox 32-bit configuration and addons) it's also rather buggy. Because of Mozilla's decision it's likely to become moreso, if not disappear altogether. This combined with the decision to effectively abandon Thunderbird is pretty ominous. Mozilla is contracting, jettisoning rather than expanding or even maintaining. Is the future of Mozilla really at such risk that this is necessary?

ASLR. At least Firefox is open source and has more eyes looking at it,

BULL! Nice catchy OS mantra there and its totally full of it as usual. I'll take one good eye over a 1000 blind ones any day. Finding bugs in your own code is hard. Finding bugs in someone else's much harder. And without out very good structured code documentation and design process (something sadly lacking in a lot of open source projects - I know I've tried for a few) is a total nightmare. It's something only the very best security analysts are good at and I REALLY doubt many more of them are looking at Firefox than internally/on contract at IE. Apart from the ones they hire direct you basically are reliant on people's good will and spare time and with vast amounts of code and no overall organisation that's wasted by a lot of repeated/redundant effort. Also many classes of bugs are actually more obvious at the ASM level where confusing higher level abstractions can mask the problem. Case in point, the famous Debian random number thing: part automated code review by people not expert on crypto led to a critical loss of entropy after their "security" modification of the rand function, giving people free range to play with code can backfire...

Don't get me wrong I am not anti-OS, I just don't think is automatically "better" as a development model. Secure code starts at the definition & design and continues through the implementation "process" & structure. Going back and fixing it later is very hard as MS has found to their cost, at least they are applying these principals to their new development.

Quote:

32bjt ASLR is still pretty good, you have ~10 known DLLs loaded in a process and ~3bn places to put them, odds aren't great.

Try 256! Ok, well the order is randomised after the start point too so its a lot more than that.

DLLs need aligned addresses so can only be placed at 64k aligned boundaries, you don't want full randomisation either as it would fragment your address space leading to issues with memory allocation so they are kept together and limited to the top part of the address space. Also, by default (with out /3GB boot option) windows is split 2GB/2GB user/kernel. It's for these reasons ASLR benefits greatly from 64bit.

Guess I'm just gonna switch to Chrome then (which, according to another Ars article, fares way better under both Win7 and Win8).

Another reason for this change is also because Firefox and Thunderbird both use about 300'000k of memory every time I boot them up. They just keep eating and eating. Plus, every time I close Firefox and I try to boot it up again, it tells me I need to kill the process. So I open Task Manager, go to Processes, and lo and behold, just as I click on the tab, it disappears! I honestly need to click on the tab to close Firefox

But I'd still like to know, am I the only one having problems with this?

To moan about how FireFox isn't 64-bit compatible, when the default browser is set to run in 32-bit mode, is just stupid. The vast majority of users continue to use IE, and don't do any special configuration of it beyond perhaps the start page and loading up on toolbars and plugins. So the vast majority are using a 32-bit app. And you have to [as far as I can determine] have installed 64-bit Windows to begin with, which less than 1/2 of all users have done [at least as googling it can determine].

Beyond Microsoft's crazy 64-bit support [separate 32 and 64 bit OS and application installs, where the end user needs to make sure they install the right version], the end-user can't be expected to understand that they should use the 64-bit version for the high-level of security it may provide [assuming it will work on their system].

Actually the default is Metro IE, which is x64 in Win 8 x64. Also what difference does it make if it's the default? MS leaves 32-bit as the default on the desktop version (I presume) because newb users are likely to not understand they need to switch to 32-bit from x64 to get some plug-ins to work, where as the browser experience won't be broken for anyone if they don't know they need to enable x64 to get that. Because of this, you think Mozilla is justified not offering an x64 option at all? Makes no sense, if users want the option of x64 for memory and security improvements they should be able to have it, default settings have nothing to do with anything, it's just a red herring.

Also, as a side note. Mozilla is working on a new browser engine called Servo (https://github.com/mozilla/servo). It's built in their own language Rust. It should address a lot of issues that people have with existing engine. Hopefully something comes of it.

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.

Which, for me, usually happens after a single day of using it. The second it comes close to the 2GB-memory limit, the program goes south. Very annoying.And it's really sad that 64bit-CPUs aarevailable since 2003 or 2004, yet Windows (and most programs for it) is still mainly slithering around as a 32-bit OS.The reasons Mozilla is giving for killing off 64-bit-Firefox sound like they'd have to fix bugs! EEEK! Really sad to see what Mr Dotzler et al. have done to Firefox in recent months.And the big catastrophe called Australis is yet to come...

What's with all the hate for Mozilla for making a change that has literally no effect on people's browsing experience but will allow them to accomplish their goals of an open web much more efficiently? That's not cool. That's really not cool. You people have no idea what it's like to produce real software that has to run on millions of machines. What a world where people would betray the single organization that dragged us out of the dark ages of web browsing for such a stupid reason. Mozilla is fighting for you...

What complete and utter horseshit. If Firefox's source is such a clusterfuck that such a simple build variation introduces heretofore unseen bugs, they're still in the dark ages you speak of, and no amount of eyes will make anything more secure. If their add-on ecosystem relies on platform-specific APIs, they're fighting against the 'open web' you speak of. If they're simply too lazy to support such a build, they're not fighting at all, they're relying on the user's lack of knowledge and complacency, which is precisely what Microsoft did with IE 6; see the "what does the user care if it's standards-compliant or not?" arguments from that time.

Case in point, the famous Debian random number thing: part automated code review by people not expert on crypto led to a critical loss of entropy after their "security" modification of the rand function, giving people free range to play with code can backfire...

You only know about this security oversight because Debian has a policy of full disclosure, Microsoft does not. Isn't that great? I'm willing to wager there are 10x more unknown RNG bugs in base Windows than in base Debian.

Case in point, the famous Debian random number thing: part automated code review by people not expert on crypto led to a critical loss of entropy after their "security" modification of the rand function, giving people free range to play with code can backfire...

You only know about this security oversight because Debian has a policy of full disclosure, Microsoft does not. Isn't that great? I'm willing to wager there are 10x more unknown RNG bugs in base Windows than in base Debian.

No, Windows was/Is/will be reviewed by people like the NIST, various 3rd party companies & governments. BTW Debian's RNG was found by accident (someone observed OpenSSL's keygen was non random) and not by open source code review. So that code, open for everyone to see was not picked up on for over a year - your point is?

Closed source projects are often susceptible to "security through obscurity" practices which are frowned upon by virtually the entire computer security community.

Just because they can doesn't mean they are though, do you really think something like IE doesn't get reviewed by people outside MS? Really?

That's not the point. Even if they have outside people (which totally contradicts your earlier argument about coders being the best at reviewing their own code, which is 100% false by the way) that doesn't preclude them from practicing security through obscurity from the POv of the general public.

Stubabe wrote:

Peaceful Creature wrote:

A few hundred? Can you show me your math? As an example, I'm pretty sure you can do more than a few hundred malloc() calls without it failing. Sounds like hyperbole.

See my post above where I point out the limitations due to the cost trade off of ASLR. What the hell does malloc have to do with module placement anyway? "Sounds like hyperbole".

Case in point, the famous Debian random number thing: part automated code review by people not expert on crypto led to a critical loss of entropy after their "security" modification of the rand function, giving people free range to play with code can backfire...

You only know about this security oversight because Debian has a policy of full disclosure, Microsoft does not. Isn't that great? I'm willing to wager there are 10x more unknown RNG bugs in base Windows than in base Debian.

MS source gets reviewed by people outside of MS, second, source doesn't really help finding bugs because most good hackers are as proficient in assembly as C++. In my opinion assembly is easier to find bugs in, because it's one simple statement per line and easily parsed by the brain, but that's just my opinion. If it's true that open source helps the good guys find bugs, then it helps the bad guys too, and I'm pretty sure no complex source code like debian is ever going to have all bugs found, so isn't it less safe to run open source (according to your logic and theories)?

I've found myself using Chrome more than Firefox recently. I've been using Firefox almost exclusively since the days of beta.

Firefox has taken a downward spiral in terms of stability and speed, since around version 7. The old 3.6 versions were the sweet spot with Firefox. It just worked, it was fast, it was stable. Now they're putting out a new version every other day, I think they've ruined it.