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.

> In short, the designers are (willfully?) ignorant of the fact that
> not everyone uses their web browser exactly the same way
> they do.

Aren't you make that mistake yourself? I know our designers collect a lot of data on what many users actually use. More data than individual Slashdot commenters have collected, I expect.

> Any time they change the interface, add an easy-to-find
> checkbox under the options to restore the old functionality.

That leads to an explosion of difficult-to-understand checkboxes in the UI, and an unmaintainable mess under the hood.

> "Automatic handling of pdf and ogg files" - I have a pdf reader
> already. I dont need another one, and I dont need one
> 'integrated' in my browser, period.

From the release notes: "audio/video .ogg and .pdf files handled by Firefox *if no application specified*" (emphasis added).

> "loaded with new features for developers." Pretty sure that
> means for advertisers.

You just made that up.

Preventing canvas tracking isn't simply a matter of fixing a bug. A solution would require something like "don't use the GPU" or "don't use platform font rasterization", either of which are completely unacceptable for most users due to degradation of performance or visual quality.

If you've got a simple fix to canvas tracking, let the world know what it is, OK?

sendBeacon was already possible with JS using XHR, just in a slower and more user-unfriendly manner. And unlike XHR, you can disable sendBeacon without breaking the Web, so it's actually better for privacy.

However, if you want to completely prevent any sendBeacon-like activity, you need to just disable JS on that page.

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...

Considering fission weapons have been around for 70 years, we've done surprisingly well at limiting their proliferation. I think mass-market availability of fission weapons is pretty far down the list of things to worry about. However, terrorists and rogue states having them in small numbers is definitely high on my list.

Mass-market small-scale kill-bots based on rockets and drones are also high on my list.

Unfortunately the most effective method to prevent use of such weapons will be to put a chip in everyone's head. I honestly think that might be worse than mass murder, but you can imagine it looking attractive both to the Powers That Be and the public.

We agree that alpha channel and animations are required features for any next-gen image format, but that doesn't change the analysis. It doesn't make sense to try to get WebP support everywhere for those features or for small compression gains, when in a couple of years or less we could introduce a new format with those features and big compression gains.

The reason we're not merging WebP in a hurry is because it's not very good. The study results linked to in the article show that WebP isn't much better than mozjpeg. (This is especially clear in the second part of the study where mozjpeg is tuned for SSIM.) On the other hand the study shows HEVC *is* much better than WebP/mozjpeg, so we know a much better format than WebP is technically available *now*. We can't simply adopt HEVC as is due to patent licensing issues, but we should be able to create an unencumbered format with similar or better performance (e.g. using VP9 or Daala as a base). It doesn't seem like a good idea to try to move to WebP when we know a better format is coming fairly soon (probably within a couple of years).

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.

Agreed that it's not in the summary, but as you correctly note, it's just a "summary". Anyone who reads the underlying blog post will read this among the facts on which the court based its opinion: "The public was allowed to search by keyword. The search results showed only the page numbers for the search term and the number of times it appeared; none of the text was visible."

So those readers who RTFA will be in the know.