[whatwg] Same-origin checking for media elements

Robert O'Callahan robert at ocallahan.org
Mon Nov 10 18:50:37 PST 2008


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).

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.

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.

Rob
-- 
"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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081111/89472f85/attachment-0001.htm>


More information about the whatwg mailing list