[qwe123]

>If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.

The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".

[laumars]

There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany). Konquorer was still kHTML last time I checked, but there are with webkit ports as well if that's really what you want. Then there's Opera, which on some platforms (eg Linux) is still using it's older renderer rather than Blink (see footnote); and Otter as well. There's quite a few Firefox forks too (eg Palemoon)....and if all else fails, you can always run lynx or elinks :p

So there are definitely quite a few alternatives (the last two were obviously a joke though). Granted many are not as feature rich, but they'll still be HTML5 compliant.

Thank you for the correction on the Google Chrome/Chromium point though. Updated my post to reflect that.

Footnote: has anyone checked if this is a Blink issue or just Chromium? Because Opera, Vivaldi and other browsers use Blink but likely wouldn't have hotword. So that would be even more alternatives available.

[rockdoe]

>Granted many are not as feature rich, but they'll still be HTML5 compliant.

This is a meaningless statement. HTML5 is a moving target. And on top of that, webpage design has deteriorated to the levels we saw around 2000 again: to be usable, your browser has to mirror the most popular engines well enough that sites work.

[laumars]

Most of the browsers I exampled used popular engines (Blink, webKit, Gecko).

And if you want to get pedantic about HTML5 being a moving target, technically it's not. People often lump the other web front end components (CSS, SVG, EMCAScript, etc) under the HTML5 heading - those components will obviously have their own specification enumerations. Furthermore, a lot of the tertiary technologies that are a moving target are either experimental features / proposed drafts (ie not part of the final specification) or browser specific extensions. Most sites tend to avoid using these without fallback code for non-supporting browsers (demo sites being the obvious exception).

[dbbolton]

>There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany).

What about Midori (LGPL 2.1)? For some reason it's not available for jessie, but 0.4.3 is available for wheezy, stretch, and sid: https://packages.debian.org/stretch/midori

The latest version on Midori's site is 0.5.9: http://midori-browser.org/download/debian/

[fao_]

And as a last resort, one could always resort to telnet :)

[mnx]

Well... until http 1.x starts being deprecated :)

[prewett]

Actually, no, apparently Firefox downloaded an OpenH264 blob [1]. See message 51 at the bottom (presumably "FF" means "Firefox").

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51

[mbrubeck]

Firefox does auto-download an OpenH264 binary on systems without a supported H.264 decoder library (if this feature is enabled, which it isn't currently in Debian's iceweasel packages). But note that OpenH264 is free software available under the BSD license:

https://github.com/cisco/openh264/

Firefox downloads binaries from Cisco because Cisco can legally distribute this software in binary form in countries where H.264 patents apply, while Mozilla can't do so directly.

There was also a plan discussed to make it easy to automatically verify that the binary corresponds with the published source code, but as far as I know that work hasn't been done yet:

https://github.com/cisco/openh264/issues/893

Also, if you have the correct gstreamer H.264 plugin installed, Firefox should use that instead of downloading OpenH264.