On Nov 10, 2008, at 6:50 PM, Robert O'Callahan wrote:
Should <video> and <audio> elements be able to load and play
resources from other origins?
Perhaps Ian thinks not:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
There's a to-and-fro discussion here:
http://lists.xiph.org/pipermail/theora/2008-November/001931.html
Jonas got involved here:
http://lists.xiph.org/pipermail/theora/2008-November/001958.html
There are three obvious options:
1) Allow unrestricted cross-origin <video>/<audio>
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
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).
I'd prefer 1 or 2 (assuming the restrictions assumed by 2 are
reasonable).
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.
Reasons to disallow cross-origin playback are a little less obvious.
The main issue is the need to avoid leaking information from, say,
intranet.example.com when an example.com user visits evil.com. The
threat is that an evil.com page tries to guess a URL in
intranet.example.com, 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.
One thing to keep in mind is the possibility of someone using cross-
origin <iframe src="http://example.com/video.ogg";>. (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.
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.
QuickTime offers a fairly rich API; in fact many things now in the
<video>/<audio> API were partly inspired by the API of the QuickTime
plugin, when Apple proposed them. And the newest QuickTime plugin is
being updated to be even closer to the HTML5 media element API.
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.
I agree, the behavior should be interoperable.
Regards,
Maciej
