On 03.05.2023 21:08, Michael Niedermayer wrote:
A quick check for example shows that even something as simple as the
HLS BBC Radio streams will fail _all_ checks, since the playlists are
hosted on another host entirely as the media, thanks to akamai live
streaming.
Playlist here, as an example:
http://a.files.bbci.co.uk/media/live/manifesto/audio/simulcast/hls/nonuk/sbr_low/ak/bbc_radio_one.m3u8
yes, thats why it says RFC in the subject, i had expected that a bit already
still OTOH, blocking these by default is the safer option, i mean if a user
does a
./ffplay http://trustedfoobar.org/cutevideo.avi
would she expect that video to access http://127.0.0.1/ and later
http://evilhost/localwebscan-success
I think this should not be possible by default settings, its unexpected
Coming from the other side -- If the user needs to set the flag for
nearly all streams, then they are not going to check in the future and
just set it, defeating the purpose of them. At which point we might as
well not burden them.
Yes, we need a system that is secure and works in most cases.
What about doing what actual browsers do, and reading the
Access-Control-Allow-Origin HTTP header, and checking if the current
origin is allowed?
This does not really work for local files. Best you could do is check
for "*" or not.
But would at least fix the BBC+Akamai case.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
