Of course it has an "positive" aspect because after all, it does offer extra functionality. Our users are not going to be charged for using it. The "risk" is on the distributors side. I strongly oppose package names that indicate ffmpeg would produce non-free or crippled code.
As for security concerns, since google does a good job with mainting their 'fork' security wise, I think we can rely on upstream to provide good security support. Most of the recent security patches came from google anyway, so there is a good chance that chrome's ffmpeg copy gets future security patches earlier than upstream ffmpeg again. For this reason, this embedded copy needs to be considered seperate from the system ffmpeg anyway.
To me, this is more a decision if we want chrome at all, as the ffmpeg part is not the biggest security concern here.
Of course it has an "positive" aspect because after all, it does offer extra functionality. Our users are not going to be charged for using it. The "risk" is on the distributors side. I strongly oppose package names that indicate ffmpeg would produce non-free or crippled code.
As for security concerns, since google does a good job with mainting their 'fork' security wise, I think we can rely on upstream to provide good security support. Most of the recent security patches came from google anyway, so there is a good chance that chrome's ffmpeg copy gets future security patches earlier than upstream ffmpeg again. For this reason, this embedded copy needs to be considered seperate from the system ffmpeg anyway.
To me, this is more a decision if we want chrome at all, as the ffmpeg part is not the biggest security concern here.