AMR is pretty widely used as a voice codec, Ogg is used in most major AAA games, and as for Opus/SILK, you might have used Skype before...

Depends on what mobile device? The reference code has extensive ARM optimizations, that's in fact one of the main improvements in 1.1 And yes, it can be accelerated with a programmable DSP if present, IIRC there's some support for C55x in the same reference code.

Audio decoding is fast enough on modern ARM SoC that dedicated hardware isn't strictly needed to get good battery life.

This might be due to the result of study showing that the insane bounties Google promises for top end bugs (especially for Chrome) draw many people in to look for Chrome security bugs, but that actually the expected payout for looking for Chrome bugs is exactly the same as it for for (for example) Firefox, because the latter pays more for the easier to find bugs.

Microsoft already changed their bug bounty program significantly days after the study was announced.

You had be running the specific, modified Firefox version that's shipped with Tor.

Mozilla's Firefox 17 (ESR) has been patched for this vulnerability. (i.e. it's not a real 0-day)

Tor ships their own, modified version of Firefox. I guess that's why it's ancient. The exploit they used doesn't exist in Mozilla's version as that has been patched for it a while ago.

Who do you think the W3C is? It's the browser vendors. Who do you think benefits from smaller browsers not being interoperable with bigger ones? Not the smaller vendors, I tell you.

Now, do you think the vendors with the near-monopoly marketshare on Mobile care about making competition in their market easier?

The conclusion was that multi-process Firefox isn't magically going to make the browser more responsive, and will make it use more memory instead. Actually fixing the bugs that make it less responsive does seem like a much more useful spending of developer time.

What do you need a 64-bit email client for? Bigger pointers so it uses more memory?

Depends on what the applications see. In case of Firefox OS, they'll see the Firefox JS runtime. In GNU/Linux, they see GNU libc.

It also works the other way around. Mozilla needs to convince people to use their browser and install it on desktop. If you get a Firefox phone (because it comes with the plan or whatever), you don't need to be convinced.

It's the same engine as desktop Firefox. What you're seeing is that a lot of websites send "Webkit-only" markup to Android devices. (Dolphin uses Android's rendering engine) This is something Firefox can never fix. There's an add-on that makes it pretend it's desktop Firefox, that generally stops misbehaving sites from sending broken markup. I suspect most sites will get their act together eventually.

I don't see the "slanted font" problem you talk about on my Galaxy S2, so that's rather strange. The "small font" problem can be solved by setting text size to "tiny" (yes, it's pretty retarded that you have to do the exact opposite of what you would expect, from what I understand it's because that option is completely misnamed).

News to me, to be honest. But in any case: we're quite some years later now. Maybe the Firefox phone won't be too late, but the iPhone was too early instead :P

What? Bandwidth is irrelevant there. If it's bad, both the HTML/JS based app and the native App will suffer. If it's offline, neither of them cares.

Odds are pretty big that the first phones will be ones originally mean for Android.

The main hurdle for late comers would be the apps ecosystem.

From what I understand they're banking on the fact that writing an app for Firefox OS will use the same technologies as making a webpage, which should make it viable for a huge developer community. Apps for Firefox OS will also run on the desktop browser (and the reverse), which isn't something Android or iOS can do.

It's an interest situation, for example if you compare to the need to totally recode everything for Android (Java) and iOS (Objective C).