Porting Pepper is a huge undertaking, comparable to reimplementing large parts of a web browser from scratch. Oh, and without real specs, so you have to do a bunch of reverse-engineering.

If you're willing to deliver a browser with no JIT and all the same web rendering bugs as Mobile Safari, doing that on iOS is easy enough.

It's when you think that you want to do better than that that you run into trouble.

There is no "Firefox browser" on FirefoxOS. There is a web browser UI (written in HTML+JS+CSS) that uses whatever the system browser engine is.

As roca said, there is nothing in the design of FirefoxOS that prevents someone from dropping in a different browser engine as long as it implements the relevant specs that apps rely on. But then this browser engine would then be used not only for the "web" but also for the various apps on the device. And only one browser engine can be used at any given time.

That seems like a failure in antitrust law, if true, in that a monopoly preventing non-commercial competition is just as bad as a monopoly preventing commercial competition, from my point of view.

Ah, well.

So by "business" you mean "source of money" as opposed to "useful activity"?

That's a pretty narrow definition.

Where by "nobody" you mean Google and Mozilla and Opera, right?

The problem was that ACID3 ended up testing a bunch of things that ranged from irrelevant to actively bad for the web, so it actually made the web worse in a number of ways.

This considerably soured people on an ACID4, unfortunately.... Getting it to happen will involve finding a way to pick the set of things to test that avoids the mistakes of ACID3.

NaCl is open source but tied to totally undocumented Chrome internals via Pepper, which makes it pretty hard to adopt without adopting Chrome wholesale.

Worse yet, NaCl is tied to particular hardware, which means that if it gets traction on the web the bar for a new hardware platform would become very high (think "ARM would not have been viable if this had happened 15 years ago" high). PNaCl, if/when it starts working would help with that problem, but not the Pepper dependency.

> I mean, why not?

Well, if you think the way the award is being given is not ok.

It's certainly been done with Nobel prizes in the past, including the Peace Prize (admittedly, there are only two instances of people refusing a Nobel of their own volition).

> with an active community that cares about
> standards,

Sometimes. And sometimes not so much. Compare Gecko and WebKit's CSS 2.1 support (based on the official test suite) at http://www.w3.org/Style/CSS/Test/CSS2.1/20110323/reports/results.html for example.

Or note the behavior of the editors of the Transitions and Animations spec drafts (who did nothing for a few years, until editors who were not associated with Apple took over the job).

The WebKit community has many members who deeply care about standards. How much the community overall and the project as a whole care is very variable.

> has an explicit policy of trying to behave like other
> browsers where possible

For various values of "possible". e.g. https://bugs.webkit.org/show_bug.cgi?id=36084 is a long-unfixed spec-compat and other-browser-compat issue that's "impossible" to fix because there are Dashboard widgets and such depending on the current WebKit behavior.

> listens to feedback, and fixes bugs.

Unless it's inconvenient to one of Apple or Google to
do so, of course.

But yes, generally speaking it's a reasonably run development project, which means it listens to feedback and bugs generally get fixed eventually.

> They are the opposite of IE in those critical
> respects.

You must be thinking of IE6 circa 2004 or so, when there was no IE team.

The IE team did quite a bit of listening to feedback and fixing of bugs in the late 2000s, and is doing it again now that it exists again. Of course they're not fixing them in IE6 no more than WebKit is fixing bugs in whatever fork it is Android 2.2 is shipping. But you might want to take a look at IE9 and IE10 sometime if you haven't already.

Actually, the address space is in fact key. The goal is to load a known DLL at a known address in the process address space, not a known address in physical RAM, because process address space is what you can see in the code that you will then try to run that will try to call into the DLL.

So in a 64-bit process, this technique is pretty hard to pull off, since it does in fact rely on address space exhaustion.

Sure. It would just plummet even more if it were an oil heater.

Also about your heating source. Burning natural gas or using steam radiators puts a lot more water in the air than burning oil does.

Mozilla is actively implementing the Web Audio API, for what it's worth.

SSL by default for Google since Firefox 14, back in July 2012. See https://bugzilla.mozilla.org/show_bug.cgi?id=633773

For other search engines it depends. For example, Wikipedia has asked that the search through their search plugin keep happening over HTTP for now (see https://bugzilla.mozilla.org/show_bug.cgi?id=758857 ).