One clarification. Sites that use WebRTC but only do H264 do exist - http://web.projectsquared.com/ is one of them. When you try to initiate a video call using Chrome it has a popup that says "Firefox Rocks for Video Calls!" and gives a "Download Firefox" button. It has mostly non-browser endpoints and none of them support VP8.
That said, I would have to guess that the percentage of users of projectsquared affected by this is near zero. -EH On Wed, Jan 28, 2015 at 10:07 AM, Jed Davis <j...@mozilla.com> wrote: > Short version: On desktop Linux systems too old to support seccomp-bpf > system call filtering[1], Gecko Media Plugins will be disabled; in > practice, this means OpenH264, which is used for H.264 video compression > in WebRTC. This will be controlled with a pref, > "media.gmp.insecure.allow". > > [1] Examples of sufficiently new distribution versions: Ubuntu 12.04, > Fedora 18, RHEL/Centos 7, Debian 8.0. > > More background: Currently it's difficult to evaluate the security > implications of bugs in OpenH264 with respect to Firefox, because > approximately 99.9% of Firefox instances run it in some kind of OS-level > sandboxing, but the remaining ~0.1% are fully exposed. > > Disabling OpenH264 would break WebRTC interoperability with endpoints > that support only H.264 and not VP8, but if those exist then they're > currently also incompatible with Google Chrome. Also, mobile devices > with hardware H.264 acceleration might prefer it and use more CPU/power > to fall back to VP8. > > Given the specifics of this security/usability tradeoff, we're changing > the default to security. > > Note that Fedora and Debian already disable OpenH264 by default in their > Firefox/Iceweasel (respectively) builds due to their license policies. > > Even more background: Firefox on Windows and OS X can sandbox media > plugins unconditionally, but on Linux the situation is more complicated. > We're using the seccomp-bpf system call filter (CONFIG_SECCOMP_FILTER), > which is available for ~96% of desktop Linux Firefox, with a restrictive > policy. In principle the classic Chromium sandbox would be more > compatible, but it requires a setuid root executable, whereas > seccomp-bpf needs no special privileges (nor changes to > release/test/install infrastructure). > > --Jed > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
