Internet Explorer has offered this for far longer than Chrome and it's actually quite effective when you don't click away the warnings. Note that Firefox and Safari also use the same SafeBrowsing service as Chrome does, though they have to wait for the protocol documentation to be updated before offering features like this one.

As the article points out, the service is used by Firefox (with a number of privacy improvements) and Safari as well.

>He only said that he didn't want it to work with older versions, and that it was not a lot of work - i.e. it still took some amount of work - to make it not work with older versions

He doesn't say that at all. Really. It's not even remotely in the article. He talks about dropping support for Python 2.6. This isn't an action involving work! It means you no longer care if it doesn't work in Python 2.6.

>What he appears to be complaining about is "Why do projects continue to require old Python releases?"

No, he doesn't. I re-read the article after reading your post and I have no idea where you get this.

He really is talking about dropping support, i.e. no longer caring if it doesn't work on old Python versions.

>I.e. Apple and Microsoft shitheads

Microsoft was a major contributor to Opus through Skype, both with code and by providing their patents royalty free.

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.