Open h-2 opened 1 year ago
Re-encoding is usually a line of defense against mass-exploiting client-side rendering vulnerabilities. If there's a bug like stagefright in a bunch of clients, and you simply host the original file, a single user (themselves possibly a victim of the vulnerability) could get an exploit into federated timelines and wreak all sorts of havoc. While you could in theory scan for malformed files or known payloads, that's a lot of work to maintain a blocklist that will inevitably allow some bad things through (if they never failed, we would never have these vulnerabilities to begin with). Simply re-encoding on a server you already implicitly trust is a lot easier.
Thank you for the quick reply. I hadn't considered malicious files at all 😐 But doesn't this also mean that re-encoding poses an attack surface on the server running the instance? Or are the ffmpeg-processes sandboxes in a special way? And are images are "re-encoded"?
Also, it seems that videos hosted on third party sites and included as links are also automatically embedded, or not? So does this measure really improve security?
Don't get me wrong, security is important. I just think that good quality pictures and videos are as well 😄
Steps to reproduce the problem
Expected behaviour
It should just use the file as is
Actual behaviour
It re-encodes the file.
Detailed description
There are many different problems around videos attached to posts. The quality is often bad, and it is unclear which formats, resolutions, bitrates lead to the video being re-encoded. It is also unclear why well-supported free formats (WebM) are replaced by patent-encumbered/proprietary formats (MP4).
I would humbly suggest the following:
Related issues:
Specifications
Mastodon 4.1.2 Firefox 112