Robert O'Callahan

Well, I still call bullshit. Especially if this is the best you can come up with. Let's see:

http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/

We have exactly two references to "security" :

And I want that not only altruistically, but also because I want the crazy awesome video (animation, peer-to-peer, *security*, etc.) ideas that will come from having more people, with more perspectives, fully participating in the internet.

and

(about 60% of our users are on Windows XP, which provides no H.264 codec), *to security* (exposure of arbitrary codecs to hostile content), and to user experience

None of them even slightly imply that the Mozilla team thinks H.264 is insecure.

http://weblogs.mozillazine.org/roc/archives/2010/01/video_freedom_a.html

This is an FAQ or rant if you will, which goes on and on about why Mozilla does not want to implement H.264. Oh yes, not one single word about security

This one:

http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html

indeed discusses security. It is however not geared towards H.264, but towards Microsoft's DirectShow. Using this article as a reference regarding Mozilla's stand on security on H.264 is at best a stretch and at worst intellectually dishonest.

I'm calling "do your homework, lest you look like a badly-informed fanboy".

I never thought of myself as a fanboy, but be my guest to dive into ad-hominem, when you're out of arguments.

In addition. I'm rather an uninformed fanboy then…

You need platform-specific APIs to give you direct access to the relevant hardware, which you then need to be able to use efficiently.

Yes, and Firefox already has platform-specific Direct3D and OpenGL backends. Remember that a browser today needs to be able to accelerate not just video but all content and compositing, so they already have to put in that investment. The investment in video is just an additional delta.

I'd rather see applications just feed the bytestream to the OS to decode using the best means available, even if it means support for new codecs is a bit slow. (Although an OS-level codec plugin architecture like QuickTime Components can get you software decoding for new or obscure codecs.)

Hm. "I'd rather see applications just feed the HTML to the OS to render using the best means available, even if it means support for new HTML features is a bit slow. (Although a engine-level plugin architecture like ActiveX or NPAPI can get you some sort of rendering for new or obscure features.)" How is your assertion materially different?

If my GPU has a high-quality, high-speed H.264 decoder, I shouldn't have to worry about which browsers will use it. They should all default to the OS-provided decoding and playback methods unless there are sound technical reasons not to. If I want to use a new codec that's not supported by the fixed-function decoder, I shouldn't have to worry about which web browsers have bothered to include the necessary OpenCL code to decode on my…

Sigh! When did the Mozilla ever claim that they do not ship H.264 because it's insecure?

Mike Shaver and Robert O'Callahan both -- during the early attempt to frantically spin this as more than just an ideological PR stunt -- pointed to security as a reason why they didn't feel comfortable delegating to other software. See the following posts:

http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/

http://weblogs.mozillazine.org/roc/archives/2010/01/video_freedom_a.html

http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html

Of course, they did eventually come clean and admit this was just a naked ideological PR stunt. O'Callahan's quote about the fact that delegating to OS codecs would mean giving up Mozilla's control -- sorry, "leverage" -- over what users can do with their own computers is particularly telling, especially in a debate that's ostensibly about "freedom".

I'm calling bullshit, badly disguised as a strawman.

I'm calling "do your homework, lest you look like a badly-informed fanboy".

The issue is that Microsoft will not give access to the API's on ARM systems that are required to do this.

http://weblogs.mozillazine.org/asa/archives/2012/05/firefox-on-windows-o.html

"Here's what's going on. For Windows on X86, Microsoft is giving other browsers basically the same privileges it gives IE. It's not great that you don't get those privileges (certain API access) unless you're the default browser and I think that's deeply unfair (a post for later,) but at least we're able to build a competitive browser and ship it to Windows users on x86 chips.

But on ARM chips, Microsoft gives IE access special APIs absolutely necessary for building a modern browser that it won't give to other browsers so there's no way another browser can possibly compete with IE in terms of features or performance.

This is in direct violation of the promises they made to developers, users, and OEMs about browser choice in documents which mysteriously disappeared from Microsoft's site -- remember this? I sure do."

Somehow I got it in my head that jwz implemented it. And I'm not the only one. But I can't find actual proof of the evil deed, and jwz in fact denies it -- although he does take credit for adding "MilSpec blinking". It seems that at worst jwz was responsible for eventually adding it to the linux version of Mozilla. While the original implementor fessed up last year, and actually got into mozilla's credits for it at long last: http://weblogs.mozillazine.org/gerv/archives/2009/03/credit_for_blink.html

Urk, now I'm remembering one time when I walked by jwz somewhere in SoMa, and thought "if he wasn't on the other side of the street already, I'd have to cross to avoid that evil blink tag creator". And now I'm feeling all regretful. Will the pain that tag inflicted on the world never cease?

(BTW, Microsoft are responsible for marquee.)

That's some very bad reporting from the Wall Street Journal:

"Mr. Simeonov reached out to the chief executive of Mozilla, who put him in touch with Jay Sullivan, vice president of products at Mozilla. The two spoke on June 9... The software was removed from the Firefox prototype on June 10."

But in fact the software was removed on June 8, before the conversation between Sullivan and Simeonov. Here is the Mercurial changeset:
http://hg.mozilla.org/mozilla-central/rev/76e9dd2d9322

Unfortunately, the WSJ reporter looked at the date of a Bugzilla comment, rather than the date of the change it was discussing. This was pointed out by Mozilla security engineer Jesse Ruderman, who provides more details in the comments here: http://weblogs.mozillazine.org/gerv/archives/2010/12/did_we_kill_a_do_not_track_feature.html