>On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote: >> So, in practice, because the h264 code is not sandboxed on some setups, >> we're disabling it so that vp8, which is not sandboxed either, is used >> instead. We have about the same amount of control over openh264 and >> vp8 code bases. What makes the difference? > >This is more a question for the WebRTC module leadership, but: assuming >the attacker can choose the codec (do we always secure the media content >at least as much as the script that set up the session?), the set of >vulnerabilities is the union of the codecs' vulnerabilities, and adding >a codec can only add more of them. > >Possibly also relevant: we already prefer VP8 over H.264 on desktop.
In theory VP8 is not inherently 'safer' than H.264. In practice, the OpenH264 codec is less mature, especially from a security perspective - VP8 (due to our and Google's use and testing of it) has been pretty well wrung out. We could consider moving VP8 encode/decode to a sandbox; there is a performance/memory cost to this. I don't think we've had many sec bugs in VP8 in recent years, so the risk/cost/reward tradeoff may not be great. An added concern for OpenH264 raised by various people has been that OpenH264 is a 3rd-party download, which raises concerns about the possibility of a compromised or evil plugin. We are somewhat avoiding that currently because we're doing the builds for Cisco, and we're also looking for ways to create a bit-level reproducible build setup so people can verify/validate that the binaries are what they say they are. The other aspect here is that the same concerns will apply to any EME/etc plugins using the GMP interface/sandbox; without seccomp-bpf, we cannot ensure the plugins aren't doing something evil (or tracking users), and those would be closed-source. So there's even more reason to disable GMP on these older linux systems. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
