I glumly predict that copyright-holding companies wanting DRM, "trusted platforms", regulatory capture, etc. will drive some of the damage here.
replySecure sandboxing tends to mean opportunities to make unrestricted copies.
What do you mean "video file that I'm perfectly willing to play in my browser". Isn't it safe to assume that no video file can escape the browser decoding sandbox?
replyNo, browsers have had many sandbox escape exploits related to decoding.
replyIsn't it safe to assume that no video file can escape the browser decoding sandbox?
replyIt's 'safe to assume' it's not. It's emphatically not safe to assume any mitigation is perfect.
> Isn't it safe to assume that no video file can escape the browser decoding sandbox?
replyWhy would that be safe to assume? If that were a reasonable assumption, you could just as well assume that it's safe to run ffmpeg.
I'm not up-to-speed with the current state of sandboxing in browsers, but in principle it's (on modern operating systems) not especially hard for them to sandbox the decoding into a separate process with basically no privileges beyond rendering a video stream. It's a bit trickier if we're only considering demuxing and delegating decoding to the hardware, but that's a much smaller attack surface.
replyA manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.
Yeah, then you need to stream content in real time between multiple processes. And not screw up the licensing.
replyAnd get hardware acceleration working...
deleted
replyThe parent does argues it is safer to sandbox ffmpeg yes
replyBut then you also often need hardware accelerators for encoding, so you need to use C again.
reply