Should <video> and <audio> elements be able to load and play resources from other origins?<br><br>Perhaps Ian thinks not:<br><a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104">http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104</a><br>
There's a to-and-fro discussion here:<br><a href="http://lists.xiph.org/pipermail/theora/2008-November/001931.html">http://lists.xiph.org/pipermail/theora/2008-November/001931.html</a><br>Jonas got involved here:<br><a href="http://lists.xiph.org/pipermail/theora/2008-November/001958.html">http://lists.xiph.org/pipermail/theora/2008-November/001958.html</a><br>
<br>There are three obvious options:<br>1) Allow unrestricted cross-origin <video>/<audio><br>2) Allow cross-origin <video>/<audio> but carefully restrict the API to limit the information a page can get about media loaded from a different origin<br>
3) Disallow cross-origin <video>/<audio> unless the media server explicitly allows it via the Access Control spec (e.g. by sending the "Access-Control-Allow-Origin: *" header).<br><br>The reason to allow cross-origin playback is obvious: it's most convenient for authors. At this point in time few, if any, major file hosting sites support Access Controls in any way.<br>
<br>Reasons to disallow cross-origin playback are a little less obvious. The main issue is the need to avoid leaking information from, say, <a href="http://intranet.example.com">intranet.example.com</a> when an <a href="http://example.com">example.com</a> user visits <a href="http://evil.com">evil.com</a>. The threat is that an <a href="http://evil.com">evil.com</a> page tries to guess a URL in <a href="http://intranet.example.com">intranet.example.com</a>, load it via <video>/<audio>, and get information about the file via the APIs on those elements. For example, currently Firefox reports progress events containing the size of the file; but we don't want to allow people to probe for the file sizes of intranet files. Ideally we would conceal whether the cross-origin resource even exists. We may want to evolve <video>/<audio> to include features like reporting of cues
and caption data to the enclosing page --- data that seem extremely
unwise to expose cross-origin.<br><br>One thing to keep in mind is the possibility of someone using cross-origin <iframe src="<a href="http://example.com/video.ogg">http://example.com/video.ogg</a>">. (This works in Firefox today.) This prevents access to the <video> element API and basically reduces the information leakage and attack surface to that of iframes. We might want to place restrictions on such iframe usage, to give server operators control over their bandwidth. That's a secondary question if options 2 or 3 are preferred.<br>
<br>Another thing to keep in mind is that plugins such as Quicktime allow cross-origin loads without restrictions. We don't want to put <video> at an authoring disadvantage. On the other hand, being just as secure as plugins may not be satisfactory, and we want a richer in-page scripting API than plugins tend to offer.<br>
<br>We've had some discussion inside Mozilla (with no consensus reached), and some discussion with the Theora folks, but really it's a cross-browser issue that we need to interoperate on, so I think WHATWG is a more appropriate place to discuss it. And it's something that should be settled soon since Safari shipped a while ago and we'll ship soon.<br>
<br>Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>