I suggest you take that browser from the old days, run it on today's web sites, and see how many hundreds of MB it takes. Assuming it loads them at all.

It's a matter of funding.

Looking at the chart at http://en.wikipedia.org/wiki/F... and in particular the inflation-adjusted line there tells you pretty much what the story was: at the peak of the Apollo program NASA's budget was about $40 billion/year in today's dollars (the red line in that graph is in 1996 dollars). NASA's budget today is less than $18 billion/year.

Or to put it in relative-to-the-economy terms, in 1966 NASA was 4% of Federal budget expenditures. 4% of the 2013 US expenditures (actual, not requested) would be $138 billion, according to http://en.wikipedia.org/wiki/2...

I bet if you funded NASA at that level (even just the inflation-adjusted one; I understand that the overall budget structure is quite different now from what it was in 1966, so the $138 billion number is pretty much meaningless), I bet it could produce results a lot quicker than it can at current funding levels...

That would take a lot more development effort, since plug-ins depend on a lot of functionality being present in-process with them that's based on libraries that make up a good bit of that 54MB.

On Mac, the plugin process is the same binary as the 32-bit Firefox process...

You mean have it download both versions, on 64-bit, right? It's not a matter of choosing: you need a 32-bit process to run the plug-ins in, and a 64-bit one for the actual browsing.

This is doable, and being worked on; it's just not been a top priority for various reasons.

Mac OS supports shipping both 32-bit and 64-bit binaries in a single executable. That's what Firefox on Mac does.

That _is_ a viable solution on Windows, albeit with multiple executables, but it about doubles the size of the download. Unfortunately, Windows users are very sensitive to the download size for their web browsers; past experiments have shown uptake dropping rapidly as the download size increases.

Your attempt to confuse here isn't really helpful.

Google does *sell* Google Glass and Nexus phones and tablets and Chromecast and Nest and soon Dropcams and probably more. They are "Google products" branded and sold by Google as theirs.

Mozilla only has one device that it works on directly, the Firefox OS Flame reference phone. The rest of the hardware you see out there is being made and sold by someone else.

And that's not just true of the hardware. Much of the work going on to extend Firefox OS software into areas outside of phones is being done by third parties for their products.

Mozilla doesn't build hardware. We make software, including Firefox OS. Firefox OS is a completely open platform freely available for any company to build on top of without restriction. There are dozens of companies building Firefox OS-based products today and there will be more tomorrow, covering mobile phones, tablets, TVs, set top boxes, game consoles, streaming dongles, wearables, and more. Some of those companies are working directly with Mozilla and others are taking the code and running with it on their own.

You're very welcome!

This is interesting. I was just discussing this with my friend last night, and proposed this exact solution. However, it's still a reactive solution. It will detect that you may be the victim of a stingray attack, but it won't stop your phone from connecting in the first place. But there is another potential solution, I just don't have enough experience developing android roms to say how it would have to be implemented. The idea is this: maintain a database of all know cell towers (your link to OpenCellID would do nicely, they offer their DB for download). Using a rooted or fully custom ROM, such as cyanogenmod, have the phone compare any new tower to the database prior to connecting. If it doesn't exist in the database, red flag it and don't connect.

The question is, can this be done on the OS level, or does it have to happen on the driver level? If it can be done at the OS level, easy peasy, just modify the code to establish tower connections to include this check. If it has to happen on a driver level, it gets trickier. Most phones use proprietary binary drivers for their cell radios, so they couldn't be readily modified. However, it may be possible to load an intermediate driver, which in turn loads the proprietary driver. If it could be determined which driver calls involved connecting to a new tower, you could just pass through everything else, and only pass through calls to the tower connect function if they passed your database lookup. Trickier, but doable. Because really, you want to avoid connecting to these things at all. Nice though it is to see you're being attacked, it's better to stop the attack before it starts.

Do you mean the "Load images automatically" setting?

The preference for that seems to still be in about:config. It's called "permissions.default.image" and the values are documented as: // 1-Accept, 2-Deny, 3-dontAcceptForeign

A government's just a body of people. Usually, notably ungoverned.

I wish you were right, but I've spoke with one of the main developers about this and Firefox is indeed using the SDK.
Unless Google opens up things on the desktop, Firefox will likely not be getting Chromecast support anytime soon.

You're mischaracterizing Brendan's position on DRM, as I'm sure he would tell you if you just asked him personally. I strongly recommend you do so.

He doesn't like DRM, and neither does anyone else at Mozilla, but you do realize that he was CTO and then CEO while most of the negotiations with Adobe were happening, right?

We've tried sandboxing the plug-in process Flash runs in. It breaks all sorts of existing Flash-using stuff, unfortunately.

The benefit of having a sandbox from day 1 is that you don't have that problem.

The difference is that the CDM will be sandboxed in a low-privilege process with no direct access to the OS and kernel, which is not at all how Flash works.